I am surprised to see this post from bram cohen, as he himself had a heated argument with linus torvalds on git design.
http://www.gelato.unsw.edu.au/archives/git/0504/2153.html http://news.ycombinator.com/item?id=505876
Git can't be made consistent
11–20 of 42 posts
Re: Git can't be made consistent
#12I stopped reading after the first sentence. The author takes some liberties with the definition of "eventual consistency.". Either he doesn't know what it means, or he likes to demolish terms which used to be defined precisely.
On a related note, to establish the credential of the author, he is the creator of BitTorrent protocol. http://en.wikipedia.org/wiki/Bram_Cohen
And has worked quite a bit on the revision control diff/merge problem, e.g. http://bramcohen.livejournal.com/37690.html
Re: Git can't be made consistent
#13Note that darcs implements the "expected" or "naive" semantics, at the cost of edge cases that have exponential time (rather than going ahead with unflagged inconsistent merges).
Was the Camp project expected to create a non-exponential algorithm at the edges?
Re: Git can't be made consistent
#14Nice to see Bram Cohen coming to the same conclusion I did. Having two branches constantly cross-merging is a bad idea, no matter what SCM you use.
I'm pretty sure the example in this article wouldn't confuse git: weirdness like this is the reason git has the "recursive" merge algorithm instead of just doing a plain three-way merge. A recursive merge basically tries to merge some of the parents together before doing the final merge, which resolves this sort of case. I do criss-cross merges between git branches all the time with no ill effects. Maybe non-git VCSe…
You need to do criss-cross merges that revert previous commits on one or both sides of the merges. If you're not reverting you're not hitting Bram's corners.
This is a though corner case and I'm pretty sure you can confuse any source control system currently in production with cases like this. BitKeeper has some theoretical solutions, but we haven't gotten around to actually test them in production.
Re: Git can't be made consistent
#15I am surprised to see this post from bram cohen, as he himself had a heated argument with linus torvalds on git design. http://www.gelato.unsw.edu.au/archives/git/0504/2153.html http://news.ycombinator.com/item?id=505876
Which he lost... i.e. Linus paid no attention to what Bram said ;)
Re: Git can't be made consistent
#16I am surprised to see this post from bram cohen, as he himself had a heated argument with linus torvalds on git design. http://www.gelato.unsw.edu.au/archives/git/0504/2153.html http://news.ycombinator.com/item?id=505876
[deleted]
Re: Git can't be made consistent
#17In short: Don't be a dummy and expect git to be some kind of advanced artificial intelligence.
Someone who knows this stuff please tell me if I my analysis is correct:
I see smart people pointing out "flaws" in software, not realizing the solution requires strong AI.
(e.g. yesterday's post: http://news.ycombinator.com/item?id=2455793)
Re: Git can't be made consistent
#18In short: Don't be a dummy and expect git to be some kind of advanced artificial intelligence.
Someone who knows this stuff please tell me if I my analysis is correct: I see smart people pointing out "flaws" in software, not realizing the solution requires strong AI. (e.g. yesterday's post: http://news.ycombinator.com/item?id=2455793 )
Merging associativity doesn't require magic AI.
Re: Git can't be made consistent
#19[deleted]
Re: Git can't be made consistent
#20In short: Don't be a dummy and expect git to be some kind of advanced artificial intelligence.
[deleted]