If you never merge, but only use "git pull --rebase", you will have a straight line history and thus lose all of the "distributed" nature of the history. That's fine, but limiting. Any system that allows distributed development has to deal with parallel work that gets merged in stages. Otherwise you are no better than diff/patch (FWIW, rebase merges before rebasing, so it is also vulnerable to this problem, rebasing just A, then rebasing B is NOT the same as rebasing A + B).
OP is saying something like "when I cook things with my freezer they don't get hot." It's that non-sensical.
Git can't do (at all) what he wants to accuse it of doing wrong (because it has nothing to do with what git does). So I'm just pointing out the closest approximation to what he's aiming at is to use pull --rebase.
Personally I like to have a straight line history as a default and only merge when required. Rather than always merge by default.
Edit: Ok, I'm not sure I understand the point of the pastebin. Maybe. If you want the lower C to become X you need to git checkout master and then git rebase c. Not the other way around. Is that it?
> OP is saying something like "when I cook things with my freezer they don't get hot." It's that non-sensical.
No, OP is saying "when I cook my food in the microwave for 3 minutes, I get it to a very different temperature than if I cook it for 1.5 minutes first and then another 1.5 minutes"
See: http://pastebin.com/SxmwpFkY