On Sun, Dec 09, 2007 at 12:38:14PM -0800, [EMAIL PROTECTED] wrote:
Much is said about how git does merging better than cvs or svn.
I'm wondering *why* it is better.
Did someone recently invented a better merging algorithm??
The main reason is that when you do a merge, it remembers the merge, and
what exactly what went into it.
Why can't cvs and svn just replace merging code to say
they are now "just as good as git" ???
CVS would be much harder than SVN. At least SVN tracks entire trees with
real changesets. The problem is that SVN doesn't record what things were
merged in (there are conventions to put in the change history to record
this).
Without storing this information, it isn't available to merge better with.
To explain a little better:
- The basics of a merge are to find a common ancestor of the involved
versions and do a 3-way merge of these versions. SVN and git are going
to be able to do this. CVS mostly can. The 3-way merge algorithms
themselves are largely unchanged.
- Where it gets tricky is after you've merged once, and then the two
branches diverge again, and you want to bring them back in sync. The
way git represents things, when you merge before, the two branches
_are_ the same tree--it records this with a special merge commit. The
other systems don't keep track of this very well.
- The other issue is if a given branch has cherry-picked some changes and
then you want to merge the whole branch. Git has some code to try and
detect this, but I don't have any experience in how well it works.
- Merges with renames are tricky in general. As long as git's rename
detection works, it works quite well. I don't know about SVN, and CVS
doesn't track the rename at all.
- Git also has a notion of 'rerere' "Reuse recorded resolution of
conflicted merges". This happens with a long-lived topic branch that
merges several times with a master. Git will remember the resolution
to the conflicts the first time and re-use them again. Because other
revision control systems don't have this capability, most users don't
realize that this is something the system _could_ do. As a
consequence, topic branches tend to exist less often, and be shorter
lived, or merged less frequently.
Dave
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
