The idea is that if there’s the potential for conflict between patches, having a set of human eyeballs examine the situation is a good thing. Don’t silently succeed but introduce bugs.

HOWEVER, there are a few other things that greatly help:

1) Proper merge history tracking. Git can and will figure out the common ancestor for a merge simply and automatically. If you’ve ever gotten lost in a swamp of CVS branch tags, you will be amazed to learn that that’s all totally unnecessary. Git figures it out automatically for you with zero work on your part. All because it understands that history is a directed acyclic graph and not a tree; a commit can have more than one parent. Just “git merge hisbranch” and it’s done.

2) Recursive merge. The classic “unsolvable” case for 3-way merging is the criss-cross merge. On branch A are versions A1 and A2. On branch B are versions B1 and B2. Then branch A merges in B1, producing A3. Branch B merges in A1, producing B3. Then we want to merge A3 and B3. What’s the latest common ancestor, A1 or B1? Git’s recursive merge solves this in a very elegant way. (Again, in the common case, it Just Works.)

3) git-rerere to resolve conflicts automatically. If you do a merge, and encounter some conflicts, git can remember the conflict and how you solved it, and provide the same solution automatically next time. It doesn’t help at all the first time you see a conflict, but if you’re doing a lot of merging, or doing test merges (like the linux-next tree that is an automatically generated daily merge of 50+ developer trees), it can save you from having to solve the same problem over and over again.

4) Small commits and branches. The ability to do local commits lets you make many small commits rather than one big one. This (and the git-bisect feature it enables) is gits Killer Feature IMHO. With a centralized VCS, the individual developer gets no benefit from the VCS, and pressure to not make bad commits leads to longer commit cycles, which leads to larger and less comprehensible commits. With git, I get to use a VCS as I’m developing, and rather than producing a patch, I produce a branch, which is also a patch series. I can use the “infinite undo” provided by the VCS as I’m developing, and it’s far easier to read a series of small changes that introduce necessary infrastructure one piece at a time than one big feature patch.

I really want to emphasize that. The git equivalent of “cvs commit” is “git push”, sharing your changes. That’s the time you want to think carefully about whether you’re ready. CVS does’t really have an equivalent of “git commit”, which is more like the save command in an edit-compile-test loop.

Git also has significant tool support for partial commits. When you commit, you can commit only a subset of your edits. This can be as simple as not including the “CFLAGS+=-DDEBUG” line in a Makefile, or you can split your hacking into multiple commits, or commit part of it and keep working on the rest. I use this when, partway through developing a feature, I find a bug to fix or add a debugging feature to the code.

5) Git-rebase. An alternative to merging is to “rebase” your code, applying it as a series of patches on top of a more recent “trunk” version than you originally branched from. This is basically what “cvs update” does, but git lets you do it with a multi-commit branch rather than just your current edits. This is generally how merge conflicts are handled in practice. If a merge conflict exceeds the integrator’s threshold of pain, he can bounce it back to the developer and ask for the branch to be rebased on top of a more recent version. Since the branch is a series of small commits, conflicts in any individual patch tend to be simple to resolve.

6) git-rebase –interactive. This lets you edit, rearrange, combine or split the changes in a branch. So if your private development included some false starts and dead ends, or was generally developed in an order that is not the best for presentation, you can easily go back and clean it up, producing a branch to share that is in an easy-to-read order and makes you look like a programmer than never makes mistakes. It’s particularly useful for larger projects with code review requirements.

I’d be interested to hear your response on these areas.

-John

For example I’d like to read your other posts about scm / version control / git; currently I cannot without browsing through all other posts, some of which (like motorcycle gear posts) I am not very interested in…

This post is filled under Uncategorized

There’s one caveat to cherry-picking, and this applies to centralized systems that can do it too: to do it well you must have commits that are a self contained and atomic as possible. If you make a commit with multiple features/fixes in it and later on you decide not to include one of them there’s no simple way to exclude just the bit you don’t want, because it’s mixed in with all the others.

Actually, with git, you can – the power of rebasing allows you to go back, split the commit sensibly into several, and then transplant the rest of your history on top of that. I guess whether this is simple depends on your definition of simplicity, but git has enough tooling to support this procedure directly. In other DVCSs you have to painstakingly monkey around with far less powerful tools, and in centralised VCSs it is for all intents and purposes impossible to do it at all.

This is what I love about git – in contrast to systems with immutable history, it doesn’t force you into any sort of careful premeditation where you try to anticipate all possible and impossible problems you may or may not realise yet. You go about business as usual, and if you belatedly notice a problem you hadn’t thought of or couldn’t even have been aware of at the time, you just go back and fix it. No sweat.

Git is humane, in the Jef Raskin sense of the word.

But it looks like there is another contender in the field of repository conversion and commit interchange between different DVCS. Well, it is not a tool, but “fast-import” format, originally created in git. Git has both fast-import and fast-export tool, the same is true for Bazaar-NG (by Canonical, GNU software) with bzr-fastimport plugin.

See also http://vcscompare.blogspot.com/2008/05/import-tools.html