Subject: Re: [boost] [git] Mercurial?
From: Mark Borgerding (mark_at_[hidden])
Date: 2012-03-21 16:28:42
On 03/21/2012 01:38 PM, Paul A. Bristow wrote:
> ... it is all too easy to find that changes collide.
> I'm unclear how git alters that (if at all) I have yet to understand.
Conflicts and merging happens. A merge in cvs or svn always caused me
to get worried and annoyed, because there was a non-trivial chance I was
going to lose something I wanted. It meant my code that I just spent
some time working on has been hacked up and spit out by an automated
merge routine. If I couldn't make sense of my code vs. the other guy's,
I was in trouble.
With mercurial, git and other DVCS's. The merge is different.
*EVERYTHING IS SAVED ALREADY*
There is no fear. You have two saved changesets, whose difference you
wish to resolve.
Often, the merge is simple and can be done automatically. Sometimes
there are conflicts. You can work on those conflicts without worrying
about losing any work.
You can rebase your changes on to those of the other guy (with saved
change bundles). You can decide his fix is a better approach and strip
out your local changes. Anything is possible. Just please don't rewrite
history that has already been grabbed by others -- that's annoying.
The point is that history is maintained before you ever merge. In a
DVCS the merge operation is a first-class citizen -- by necessity, since
every sandbox is a first class repo, complete with history and
everything you need to continue your work on the plane,train, or in the
cave of the dalai lama.
Here's a "dont' fear the merge" answer I wrote a while back with a
simple example for hg. The concepts should apply to any DVCS.
Note: Although, I mentioned rebasing and stripping history as possible
options for how to deal with conflicts, they are slightly riskier than a
simple merge. This is why mercurial requires you to add a single line to
your config file to enable these extensions. It is sort of a safety
catch on a rifle. It is still possible to blow your foot off, but not
quite as easy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk