3 ms·

Here's a quote from the article explaining what would rely on this expectation: > There are still some people who still think nothing is wrong with git; that i

• jerf 16y ago
  I think I kind of know what the author was getting at, but I'm not sure, and ending with the moral equivalent of "If you disagree with me, I guess you're just stupid" was a bit disappointing. I think the idea is the potential problems with this could emerge if you have two people simultaneously doing somewhat larger complicated merges that have this core problem perhaps more than once. I think that may be true, but the probability of this occurring is well below just plain-old-fashioned human screwups, and the solution to both ("laborious history comparison, examination, and a reset --hard to a hash by somebody") is the same in both. I really don't see how fixing this would solve any real-world problem.
  • copper 16y ago
    I thought the author was trying to get at the old Babbage quote on confusion of ideas. FWIW, I use git-svn to handle complex merges in svn because git has a better merge algorithm. While this particular situation doesn't affect that use case - I think it could, but it should be rare with (svn) branch discipline - the fact that it might is something to keep in mind.
• nevinera 16y ago
  That quote by the author says 'I expect this behavior'. It does not give some use-case that would rely on it, aside from the use case of 'I use git, and incorrectly assume that merges are transitive.' More specifically, if they pulled the same patches, the outcome would be identical. What he wants to be able to do is pull the same history by pulling different patches in that history. A patch is the diff between two repository states, and that's all it is. Sadly, diffs are intransitive.
  • ob 16y ago
    Then you're no better off using a DVCS than you are using diff and patch. Not even git (which is as dumb as it gets) is _that_ dumb.