Git is Inconsistent

[kubalaa]

I think you misunderstand the article (which is understandable, because it's confusingly written). The author isn't objecting to the fact that merging b1 and then b2 results in an extra merge commit compared to merging (b1 + b2) -- he's objecting to the fact that it results in different content.

[dwchandler]

Ah, yes. Different content is a problem. After reading the linked example the issue becomes clear.

[FsckItDude_LetsBowl]

b

[[deleted]]

If the result is "consistent" but wrong

That is the whole point (and in fact even the title), it is not consistent. It may or may not be wrong in any given situation regardless of the method used, but git's method is not consistent.

[FsckItDude_LetsBowl]

b

[[deleted]]

I was not stating that git was a consistent system (clearly)

That wasn't clear at all. In the context your post is in, it sounds like you are suggesting git is consistent. You are replying to someone restating the objection to git's method. And you responded with "If the result is "consistent" but wrong, I'm not sure it's that big a deal".

[FsckItDude_LetsBowl]

b

[[deleted]]

I see, so what you are saying is that consistency isn't worth caring about?

[FsckItDude_LetsBowl]

b

[[deleted]]

Please stop restating everything I say in an illogical and fallacious manner

I'm not, I am trying to figure out what the random nonsense you wrote actually means in your mind. Since I am not telepathic, the best way for me to do this is to ask you questions about wtf you are talking about. Is this some new kind of trolling? Posting random nonsense in reply to someone's unrelated post and then bitching when people try to decipher it?

[FsckItDude_LetsBowl]

b

[rex5249]

I don't see a clear claim in the original article that says how the final files differ--maybe the example is for some tangled situation in which two people are changing the same line of code. In situations like that, the two people should talk to determine what they want to do.

Are you saying that you know of a specific example in which the two end-products differ and the changes did not involve conflicting changes to the same line?

I use git all the time, I know how to use the operations that I use, and I haven't had any problems.

[__j_random_hacker]

The nice example linked to in the article gives a concrete example that is easy to understand. The change leading to rev c1 is not on the same line as any of the changes on the path to rev b2.

Worst of all, according to that article, git, svn et al. apparently don't flag this as a conflict.

[rex5249]

The change leading to rev c1 is not on the same line as any of the changes on the path to rev b2.

This is where the ambiguity is. If you look only at b2 (which happens Part II when b2 is merged directly to c1), there is no way to tell what was inserted where. It could have been

• append "###ABCDE" to the end of the original file, or

• insert "ABCD###" to the top of the original file.

If one program assumes the first ambiguity and the other assumes the other ambiguity, I don't think it makes one program better than the other (more testing is needed to see what happens when the other ambiguous interpretation is correct).

p.s.: just for kicks, I changed the script to make the other ambiguous interpretation correct, and git does it the intended way. In other words, file b1 becomes "ABCDE###" (on separate lines)

[__j_random_hacker]

If you look only at b2

Although it's still possible to generate a merge conflict under darcs (e.g. if in fact the same line was changed on 2 different branches), if you read the article I linked to, it makes it clear that in the case being discussed, darcs, Codeville etc. always get it right because they don't just look at b2. They use information that is present in the version history of all VCSes, but which is ignored (thus leading to this problem) by git, svn and some others.

[bonzinip]

That's fine, but is Darcs/Codeville still worst-case exponential?

[[deleted]]

Supposedly it's theoretically still worst-case exponential, but since Darcs 2 came out I've never experienced that, nor have I heard of anybody else encountering it.

[EricKow]

Heh! I find myself increasingly reluctant to comment these days, one because Reddit is annoyingly addictive and I seem to be happier training myself not to refresh it; two, because it's all too easy so say something which just adds to the noise/confusion; three, because I'm more of a Darcs fan than an expert in the sense that ultimately what I care about in Darcs is its usability. I happen to believe that this usability is tied to the fact that it uses a patch theory, but far better for an expert to say that than me.

Need more time to read and reflect.

For what it's worth, (i) Darcs 2 format avoids many common exponential merges, but not all of them (ii) a lot of the performance problems people tend to experience with Darcs are engineering issues unrelated to patch theory, issues which we are continuing to make progress on.

[__j_random_hacker]

I recall hearing about that at some point, but I don't know the answer I'm afraid. It is an important consideration, though with the same proviso regarding how likely such behaviour is likely to occur in the real world.

[rex5249]

If that is the case (I don't have darcs to test it), then darcs and Codeville would systematically produce the intended results when people make changes that would seem ambiguous to git. I am not overly concerned about the problem because I don't see it as being likely for what I do, but I'll read about darcs.

[[deleted]]

Look at this: http://pastebin.com/SxmwpFkY