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

You are missing the point.

[ext_513595]

Git does not attempt to achieve "eventual consistency" because that requires an authoritative notion of The Truth, and Git was explicitly designed to AVOID that

Re: You are missing the point.

[bramcohen]

If you find it so important to not have blind merging, I suggest you do all merges by using diff and manually selecting which hunk wins in each case. That will free you from the confines of a tool which actually keeps track of things for you.

Re: You are missing the point.

[ext_513595]

Whenever I conduct a merge, I DO use three-way merge tools, but I have learned to ALWAYS ALWAYS ALWAYS sanity-check the conclusions it reaches, hunk-by-hunk

Re: You are missing the point.

[bramcohen]

You seem to enjoy spending time messing around with your version control system.

[ciphergoth]

I think Monotone's mark-merge escalates all these decisions to the user, FWIW.

[bramcohen]

I believe you're correct, and also that mark-merge will get horribly over-conservative in situations where two different branches keep pulling old versions of the other one for an extended period of time. It seems like nothing supports that use case well, and noone has ever really complained about it.

Complaining about pathological insanity...

[ext_513595]

Why WOULD they complaint about it?

What you describe is a pathological scenario wherein the only fathomable explanation would be people making random guesses about what does or does not actually *work*. You are describing monkeys at keyboards.

There simply is not a good reason to go back and forth between historic versions repeatedly with no awareness of why one is doing it, and whether or not one's reason for doing it should override the judgements of others.

Re: Complaining about pathological insanity...

[bramcohen]

You shouldn't be so sharp in your judgements unless you actually understand what is being discussed, which in this case you clearly don't.

Re: Consistency

[bramcohen]

I believe the terms you would like are 'commutative and associative'. What I mean by 'eventual consistency' is that if everybody eventually pulls in all the same history, they'll all wind up at the same value (assuming no merge conflicts). At least that's what I think I mean, I'm just trying to use the same terminology as earlier posts.

I suspect that every layer is a spoiler for eventual consistency by the way. It just plain won't happen unless you do some very artificial canonical reordering of changes when new history comes in, and that can result in bizarre codebase jumping around in some edge cases.

[wasdely]

Your sixth sentence would read much better as:
Git follows the semantics which you want 99% of the time, at the cost of having some edge cases upon which it's inherently just plain broken.

[bramcohen]

Those are grammatical rules up with which I will not put.

[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.