4 ms·

There are two things most commenters in this thread have missed: 1) The article talks about auto-merges. If the code is "too close" by some definition of close

by ob 15y ago

There are two things most commenters in this thread have missed: 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.

davidmathers 15y ago
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.
- ob 15y ago
  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). See: http://pastebin.com/SxmwpFkY http://pastebin.com/SxmwpFkY
  - davidmathers 15y ago
    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?
    - ob 15y ago
      > 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"

by ob 15y ago

davidmathers 15y ago

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.

ob 15y ago
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). See: http://pastebin.com/SxmwpFkY http://pastebin.com/SxmwpFkY
- davidmathers 15y ago
  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?
  - ob 15y ago
    > 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"