Yes, but I would consider things like a two-stage commit process more focused on people who review lots of changes and do partial commits on those changes rather than those who do small changes on a personal branch.
I agree with you on that. However, the way I see it is that git allows for small commits (with git commit -a) and large ones (with git add and git commit) while an enforced one stage commit process makes it more difficult with large/complicated commits. I guess that refactoring work probably involves commits that touch many files and can be complicated. It does not require a large team to get large commits (even when I work alone I usually do partial/large commits when I review old code).
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!
Heh, I used CVS for my Master's thesis, but I'm not suggesting that ;)
In case it wasn't clear, I was just pointing that to show that git is very practical for me while I mostly work alone and on projects that are far from being the linux kernel. I am not saying that bzr wouldn't be equally good for me, just that git is not "for" kernel developers anymore.
I remember from previous discussions that one difference between git and bzr which might influence the choice is their handling of remote branches.
I'm not sure that I understand what you're saying with the git stuff, but with for instance the Launchpad plugin and Bazaar you can create branches and push to them at the same time. [...] I'm not sure if that matches what you were saying. But, hopefully it answers your question :)
It shows that this is easier with bzr which was the question indeed.
Finally, in terms of functionality, git supports importing a specific revision of another git repository as a submodule.
<snip> > I don't know if bzr can do all that.
I'm pretty sure that bzr quilt can do that,
From what I read about quilt (or loom), it is very different from git
submodules. Git submodules are similar to svn:externals. In bzr the equivalent would rather be "nested trees": http://bazaar-vcs.org/NestedTreesDesign But I cannot figure from this page whether it is implemented or not. In any case it seems to add complexity to the base commands. I find submodules quite straightforward in git.
Let say you have an "inkscape" repository and a "libcroco" repository. You would:
git clone address-of-inkscape cd inkscape # add libcroco git add submodule address-of-libcroco src/libcroco git commit -m "Add libcroco as a submodule of Inkscape" # now inkscape contains a reference to the last commit of libcroco (number n) and the complete libcroco repository # # work on inkscape vi whatever.c git commit -a # the above command commits to "inkscape" # # now work on libcroco cd src/libcroco vi a-file.c git commit # the above commits changes to the "libcroco" repository # the only thing that changed in the "inkscape" repository is that the reference to libcroco changed from commit n to commit n+1 # # now you've finished your work on a new feature of Inkscape that required a change in libcroco. Time to push everything to the public # require the latest version of libcroco in Inkscape git commit src/libroco -m "Bumped libcroco version" # this basically says: "the reference version is now commit n+1" # commit your work in inkscape git commit -a -m "Cool new feature" # publish everything git push
So basically you have two full fledged repositories and the ability to specify on which specific version of libcroco Inkscape depends. Of course, if I understood well, the goal in the end would be to have libcroco (or 2geom or...) be completely separate and have Inkscape link to them. But submodules look like they could be a useful tool for the progressive migration towards this state so that's why I mentioned them.
JiHO --- http://maururu.net