On 03/21/2012 01:38 PM, Paul A. Bristow wrote:
[snip] ... 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. http://stackoverflow.com/questions/2968905/merging-from-another-clone-with-m... 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.