Git Can't Be Made Consistent

[bramcohen]

This post complains about Git lacking eventual consistency. I have a little secret for you: Git can't be made to have eventual consistency. Everybody seems to think the problem is a technical one, of complexity vs. simplicity of implementation. They're wrong. The problem is semantics. Git follows the semantics which you want 99% of the time, at the

Comments

[faceted_jacinth]

> In this example, one person changed a files contents from A to B, then back to A, while someone else changed A to B and left it that way. The question is: What to do when the two heads are merged together

[bramcohen]

Showing a conflict in that example would be clearly broken behavior. It could result in repeatedly showing the exact same merge conflict over and over again, between the exact same values, on later merges.

[faceted_jacinth]

> It could result in repeatedly showing the exact same merge conflict over and over again, between the exact same values, on later merges.

Why? Any merge establishes definitive ancestries for each line of code, and when you are merging "A - B - A" with something, you are supposed to tell it that the conflicting lines come from the base snapshot, not from your "reversal". In fact, when you want to revert a commit, instead of re-committing the previous version you should merge with it, I think.

Was that the problem that you were thinking about?

[bramcohen]

Merging with an old version to undo changes just plain doesn't make sense - the whole point of history is that it knows that later versions supercede older versions.

[faceted_jacinth]

Also, to clarify: here a merge would be quite different from an ordinary commit but with two parents, here it would have to store the choices the user made, from which of the parents he picked the lines. Plus maybe some additional modifications he had to make, as a separate commit.