Git is Inconsistent

1) The article talks about auto-merges. If the code is "too close" by some definition of close, you get a conflict that needs to be manually merged. The article does NOT talk about manual merges.

2) The article is titled "Git is Inconsistent", it doesn't claim Git is WRONG, it claims it is INCONSISTENT. It does different things depending on how you merge and when.

I think consistency in a DVCS is a desirable goal. It should not matter whether you pull A then B, or pull B then A, or whether given a series of commits, you pull after each one, or just once at the end. The end result should be the same.

That it is a rare occurrence only makes it worse. You will mostly trust the auto-merge algorithm until you hit the corner case and it will be very expensive in terms of time/money to fix the mistake.

Git's brilliance/stupidity is precisely that it only tracks contents, so although it could get the right answer it makes it very expensive to do it.

I can understand your confusion, given the seemingly separate use cases for reset, but in fact, it makes perfect sense. Reset always does what it says it does. Let's break it down:

git reset --mixed will make your current HEAD point to , reset the index to , and leave your working tree alone. This is useful for "uncommitting" the last commit, e.g. so you can split it up into smaller commits. Example:

  git commit -am "lots of changes"
  # realize you should really do better
  git reset --mixed HEAD~1
  git add myfile.py
  git commit -m "implemented feature x"
  git add yourfile.py
  git commit -m "bugfix #3182"

  git add dontstage.py
  git reset HEAD dontstage.py == git reset --mixed HEAD dontstage.py, since --mixed is the implicit default

Now, if someone (e.g. easy git: http://people.gnome.org/~newren/eg/) wants to make git reset HEAD to unadd, that's fine by me. I'm speculating here, but I imagine that the Linus/git dev point of view is, why call it anything other than exactly what it is? It's just nice and elegant that it happens to suffice multiple use cases.

The more you get into git, the more you start to realize why some of the commands that seemed arcane in the beginning are simple and elegantly named.

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.