3 ms·
I think this post is missing the point entirely. The strength of git has nothing to do with "magically resolving all possible corner cases". That was never the
by hasenj 16y ago
I think this post is missing the point entirely.
The strength of git has nothing to do with "magically resolving all possible corner cases". That was never the intended purpose of git.
To quote Linus himself:
> The important part of a merge is not how it handles conflicts (which need to be verified by a human anyway if they are at all interesting), but that it should meld the history together right so that you have a new solid base for future merges.
> In other words, the important part is the _trivial_ part: the naming of the parents, and keeping track of their relationship. Not the clashes.
http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php http://www.wincent.com/a/about/wincent/weblog/archives/2007/...
In other words, there are corner cases where git might fail to resolve conflicts automatically.
If git does manage to resolve some obscure corner case on its own, it would be mostly accidental; it's not why git is better than svn.
git would still be an awesome tool even if it didn't handle all the obscure corner cases.
- brodie 16y agoThe post talks about merging working correctly with renamed files. That's not a "corner case"; that's exactly what Linus is referring to in your quote. The author could've given an example like this where he got a conflict and that would still be an infinitely better outcome than what Subversion's doing. You'd actually know that there are changes that you need to reconcile, instead of it silently succeeding. He's not missing the point.