The article is titled "Git is Inconsistent", it doesn't claim Git is WRONG, it claims it is INCONSISTENT.
Ok. The claim that git is inconsistent is wrong. From OP:
The problem with git’s merging is that it doesn’t satisfy the “merge associativity law” which states that merging change A into a branch followed by merging change B into the branch gives the same results as merging both changes in together in one merge.
There is no such concept in git as "merging both changes in together in one merge".
I have modified a shell script written by Simon Marlow that illustrates, using git, how merging two patches separately can give different results than merging two patches together.
The shell script doesn't do what is claimed. It can't because git has no facility for "merging two patches together". Git can only do 2 things with patches:
1. generate a patch
2. apply a patch
But! git has a function which is equivalent to combining 2 patches in a single merge:
git pull --rebase
The shell script does not use this command. It first applies 2 patches separately. It then applies 1 patch separately.
There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know what to say to those people.
This is just incoherent. I have no idea what to say in response because I have no idea what the intended meaning is.
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"
Ok. The claim that git is inconsistent is wrong. From OP:
The problem with git’s merging is that it doesn’t satisfy the “merge associativity law” which states that merging change A into a branch followed by merging change B into the branch gives the same results as merging both changes in together in one merge.
There is no such concept in git as "merging both changes in together in one merge".
I have modified a shell script written by Simon Marlow that illustrates, using git, how merging two patches separately can give different results than merging two patches together.
The shell script doesn't do what is claimed. It can't because git has no facility for "merging two patches together". Git can only do 2 things with patches:
1. generate a patch
2. apply a patch
But! git has a function which is equivalent to combining 2 patches in a single merge:
git pull --rebase
The shell script does not use this command. It first applies 2 patches separately. It then applies 1 patch separately.
There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know what to say to those people.
This is just incoherent. I have no idea what to say in response because I have no idea what the intended meaning is.