I won't vote because my opinion does not really matter for this and because I have no experience with bzr but I thought I could add some comments:
they list the feature of "staging area", which is a total misfeature. It basically means you need to commit twice, instead of supporting an easy "uncommit" command. I'll never understand that, and in arguments I've had on the topic most git user end up saying "committing shouldn't be that easy," which just makes me laugh.
As Ted, I was initially skeptical about this staging area and could not understand why committing had to be that complex. Yet I grew to appreciate this feature when I need to commit *some* of the changes in the tree but not all of them.
When several files are involved, instead of having to type one long command with all the paths, you can just move around in your source tree and put files in your "staging area"-bag before throwing all that in a commit. I gives you a chance to review which changes are left in your working tree (because git diff ignores the changes in the staging area by default) and helps you not forgetting anything.
What's even more powerful is when committing only part of the changes in one/several files. Let say you are reviewing some files looking for a bug and, in the meantime, you correct some typos or weird syntax which is unrelated to the bug. You can first put the changes related to the bug in one commit and then put the syntax cleaning in another, even when those changes are in the same file(s). That makes for a much more sensible history. Can bzr commit only chunks of code in a file?
(NB: you could also do a "git stash"/"bzr shelve", work on the syntax cleaning, commit that and go back to working on the bug but this is not half as practical as working down the files solving both issues in parallel and sort them at commit time.)
I care about easy-of-use, and git comes with loads of negative feedback in that department. I find bzr an easy step in the right direction for continuing to do centralized VCS with trivial changes in work-flow to do DVCS. git is hugely unfriendly, IMHO.
I tried to use Git once but was somewhat intimidated, so other developers which do not use VCS tools heavily might feel the same.
I think this is just coming from the bad history git has in this department. Initially, git was very difficult to use apparently. But this has changed (and had already changed a over a year ago, when I started using it): git is now much better documented than svn for example (the man pages are comprehensive and very clear), the everyday commands are completely straightforward and there are plenty of tutorials targeting a wide range of audiences. http://git-scm.com/documentation The UI was heavily critiqued but I now find it brilliant. The feedback you get from every command is clear and helpful. Even the formatting of the output is nice: coloured status, logs, and diffs (you can even get a coloured diff in the editor where you type your commit message, which is very helpful to write a sensible commit message), diff summary per file (the lines with the + and - after each file name), clear organization of the status output etc. The CLI is so nice that I only use a GUI (GitX in my case) to commit chunks of code (which is not as easily done on the command line).
I had a non-computer savvy intern use git to collaborate with me on a project and he picked it up quickly (clone, status, diff, add, commit, push, pull is basically all you need for everyday use and all those are very simple to understand).
Among the "social problems" that I mention git mismatching our needs is the one of the target audience. The Kernel development realm is very different from ours, and I think that highlights one place where different tools are appropriate for different jobs.
It is not because kernel developers created and use git that it is only suited for them. Things like email patches are evidently targeted at them. But I use git for all my personal projects and find it completely appropriate even though they are small projects, on which I mostly work alone, on my machine. I even used it to manage the latex and svg files for my PhD thesis and found it very practical (thanks to coloured word-diff) while this is probably as far from the kernel as you could get!
I remember from previous discussions that one difference between git and bzr which might influence the choice is their handling of remote branches. When you create a local branch in git and eventually want to make it public as a remote branch, you need to: - push your local branch to the server, - move to the master, - delete the local branch (hence all your changes need to be committed), - recreate a local branch which tracks the remote one you just created. It is easier to create the remote branch directly and then check it out but I guess that, in most cases, people would start a local branch and, only after a while, need some help on it and want to make it public. I seemed to be easier with bzr+launchpad because you could create a remote branch through launchpad and then push your local branch to it easily, but I don't remember the specifics.
Finally, in terms of functionality, git supports importing a specific revision of another git repository as a submodule. Then the submodule is a separate, full fledged git repository and it is very easy to work on both the main project and the submodule at the same time. This might be useful for the progressive separation of libraries (2geom, croco, etc.) which were mentioned earlier. It would also be possible to extract the history of those libraries from the global Inkscape tree so that they wouldn't need to be restarted with no history, e.g.: git clone --no-hardlinks inkscape/trunk only-libcroco cd only-libcroco git filter-branch --subdirectory-filter src/libcroco -- --all git reset --hard git gc --aggressive git prune I don't know if bzr can do all that.
I hope that helps,
JiHO --- http://maururu.net