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

"confusing crap" vs. "nice example"

[ext_514819]

Dear Bram

Re: "confusing crap" vs. "nice example"

[bramcohen]

The problem with dealing directly with the positioning example is that my argument is completely semantic, I'm basically saying 'maybe the user really did mean for it to be a completely fresh version, and just ignore the history'. Which is basically an argument in favor of fuzzy matches in general. Examples where there's a lot more editing in the interim make it much more likely that the user really didn't follow all the line moves and simply wants the fuzzy match.

My point here is about the higher-level thesis - that consistent merges are just plain impossible. An argument can be made for it in the line ordering case as well, but it's a weaker one, hence my use of just this example.

Re: "confusing crap" vs. "nice example"

[ext_514819]

Now you're making a good argument. (Unlike off-handed words like "confusing" and "crap".)

I don't yet see if it is a correct good argument, though. I don't see a situation in which the user wants a fuzzy match for the merge. Every edge in the graph represents a diff that a specific user approved. This conversation is not about the fuzziness inherent in the production of those diffs, right? (That is a different but related issue so it can confuse discussion.)

So with this graph:

a
/ \
b1 c1
|
b2

assuming that the user who generated the diff from a->c1 generated the diff they intended to, and the user who generated the diff from a->b1 did the same, and the user who generated the diff from b1->b2 did the same, then I don't think the user who asks for the merge of the two branches would ever want the fuzzy solution which ignores the a->b1 edge and the b1->b2 edge in favor of using just the a, c2, and b2 states.

[kragen]

On Reddit, a user quite reasonably asks:

Having multiple branches which are constantly pulling in each others's changes at a slight lag is bad development practice anyway

Wait, ain't that the scenario for which DVCS are meant?

Are we misunderstanding what you meant?

[bramcohen]

You should generally have a master, and have branches pull from master frequently and synch to master occasionally, and when they do synch to master it should be off the most recent version.