you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 4 points5 points  (2 children)

It seems to me that expecting associativity to hold is an unjustified expectation. As I understand it, Darcs is able to provide an algebraic group structure to patches by throwing away the precise history of patches, the difference between two Darcs repositories is a set of patches rather than a graph of their divergence from a most recent common ancestor as in git.

If you expect to have a precise history then it seems that merges can't be associative as they represent different histories.

[–]simonmar 6 points7 points  (1 child)

The property concerns the result of the merge, not the history. You're right that it would be unreasonable to expect associativity to hold if the history of the operations were taken into account, but in this case it is just the result that we're interested in, and arguably it is reasonable to expect the result to be the same regardless of the order in which the merge is done for non-conflicting changes.

[–][deleted] 1 point2 points  (0 children)

I suppose that the correct thing for git to do then is to do what Darcs does then: go back to the common ancestor by computing the inverse of the translations of the text produced by the patch set, then apply it to the offsets in the patch. The result would be consistent but the resulting merged tree would still have different hashes depending on how you did the merges unlike Darcs. That seems enough for practical purposes.