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.
The 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.
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!
Look, far be it from me to always be chasing and advocating the new hotness, and declaring the ignorance of the dark ages (ie. 5 years ago), because it's very very rare in technology that something is so utterly and dramatically superior in every technical aspect as Git (or Mercurial, or Darcs) is over SVN.
I'm not going to write the usual dissertation, because I've done it before, and I personally could not care less what you use in your shop. But suffice it to say that subversion conflates the notions of repository, directory, and branch in such a way as to leave the entire system crippled beyond hope of repair, and it will always be full of nasty edge cases internally in order to support this "simplified" model.
Now I understand there are many many valid reasons why it might be necessary to use subversion, but an easier transition from CVS is not one of them. As a professional developer you undermine your credibility in the community when you say things like that.
Version control is a developer's bread and butter. Investing in using one of the good ones may be the single greatest skills ROI a developer can get. Unless you understand both git and svn intimately, you won't grok this, but let me state from hard-won experience that in SVN you can occasionally hit nightmare scenarios requiring days or even weeks to sort out a problem that could be solved in under an hour in git. Similarly, many minor hassles in SVN (such as hot fixes) become trivially easy in git. Finally, git's repository model lends itself to better understanding and knowledge transference to other VCSes, because the conceptual model (not the UI) is elegant and well-defined. I understood git's internals after 6 months of daily use better than I understood the internals of SVN after using it for more than 6 years.
I wouldn't say "fail". You'll just get a tree conflict where SVN complains that it can't merge changes because a file no longer exists. In TortoiseSVN such a conflict is trivial to resolve, because the tree conflict dialog gives the option to apply the changes to the renamed file instead: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-...
The article claimed that "svn merge --reintegrate" did not complain about a conflict, just quietly gave the wrong result. I'm the designated svnmerge.py entrail reader at work, and I've seen that make even more severe mistakes.
(They keep saying our git repo will be ready Real Soon Now[tm]. So looking forward to that.)
The article demonstrated a silent bug in a specific use case: merging a rename for a file which was modified locally.
I was responding to the generalization "don't rename files if you use branches at all". Things are not that bad. As I explained above, merging a change to a file which was renamed locally works fine: it triggers a tree conflict which is easy to resolve.
svnmerge.py was deprecated by the introduction of merge tracking in subversion 1.5, so I'm not sure why you are still dealing with that. You can migrate with svnmerge-migrate-history.py
"accepted as a deficiency" and "have found subversions merging support to be good enough" are good indicators that you are optimizing for easy-to-train rather than the-best-system. That's fine. In your case, you've probably made the right choice.
The author is explaining how this one feature that is accepted as a deficiency by svn is handled properly by git and he barely ever hears about it. He never said this is the only reason to switch to git. He does however think this one feature is representative of git's superiority.
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/...
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.