
How Git shines above Subversion at Merging - niyazpk
http://tuxychandru.blogspot.com/2010/01/how-git-shines-above-subversion-at.html
======
hasenj
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/...](http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php)

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
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.

He's not missing the point.

------
westi
So the one "small" hole in the merging infrastructure in subversion is what
makes git "shine" above subversion?

This issue is well documented and accepted as a deficiency -
[http://svnbook.red-
bean.com/en/1.5/svn.branchmerge.advanced....](http://svnbook.red-
bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.moves)

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!

~~~
DougBTX
"Don't rename files on a branch" isn't a small hole.

~~~
ryanpetrich
Really it's "don't rename files if you use branches at all" (because renaming
a file in trunk will cause merges of outstanding branches to fail)

~~~
wcoenen
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-...](http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-
conflicts.html#tsvn-dug-conflicts-tree-1)

~~~
prodigal_erik
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.)

~~~
wcoenen
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

------
tbrownaw
That's the thing about _distributed_ version control systems -- merging is
such a central operation that is _has to_ work well.

------
littleidea
Welcome to the not evenly distributed future.

