I think this post is missing the point entirely.<p>The strength of git has nothing to do with "magically resolving all possible corner cases". That was never the intended purpose of git.<p>To quote Linus himself:<p>> 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.<p>> In other words, the important part is the _trivial_ part: the naming of the parents, and keeping track of their relationship. Not the clashes.<p><a href="http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php" rel="nofollow">http://www.wincent.com/a/about/wincent/weblog/archives/2007/...</a><p>In other words, there <i>are</i> corner cases where git might fail to resolve conflicts automatically.<p>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.<p>git would still be an awesome tool even if it didn't handle all the obscure corner cases.
So the one "small" hole in the merging infrastructure in subversion is what makes git "shine" above subversion?<p>This issue is well documented and accepted as a deficiency - <a href="http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.moves" rel="nofollow">http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced....</a><p>Personally I have found subversions merging support to be good enough for the past few years and when you are introducing a modern VCS into a shop which has used VSS, CVS or PVCS for the past age it is a much easier transition for the users than git would be and provides much better merging support that VSS or PVCS users ever had!