I’ve been writing a lot about this lately, I know, but it’s an interesting landscape.
I had previously discarded git, but in light of git-cvsserver (which provides a plausible way for Windows people to participate), I gave it a try.
The first thing I noticed is that git documentation, in general, is really poor. Some tutorials that claim to cover git actually cover cogito. Still others use commands that are much more complex than those in the current git — and these just the ones linked to from the git homepage.
git’s manpages aren’t much better. There are quite a few git commands (such as log) that take arguments that other git commands accept. Sometimes this fact is documented with a pointer to these other commands, but often not; a person is left guessing what the full range of accepted arguments are.
My complaint that git is overly complex still exists. They’ve made progress, but still have a serious issue here. Part is because of the docuemtnation, and part is because of the interface. I wanted to export to diffs all patches on the current branch in a repo. I asked on #git, and someone suggested using the revision specifier ..HEAD. Nope, didn’t work. A few other git experts chimed in, and none could come up with the correct recipe. I finally used -500, which worked but is hackish.
git’s lack of even offering support for a human to indicate renames also bothers me, though trustworthy people have assured me that it doesn’t generally cause a problem in practice.
git does have nicer intra-repo branching than Mercurial does, for the moment. But the Mercurial folks are working on that anyway, and branching to new directories still works fine for me.
But in general, git’s philosophy is to make things easy for the upstream maintainer, and doesn’t spend much effort making things easy for contributors (except to make it mildly easier to contribute to a large project like Linux). Most of my software doesn’t have a large developer community, and I want to make it as easy as possible for new developers to join in and participate. git still utterly fails on that.
I tried bzr again. It seems that every time I try it, after just a few minutes, I am repulsed. This time, I stopped when I realized that bzr doesn’t support tags and has no support for emailing changesets whatsoever. As someone that has really liked darcs send (and even used tags way back with CVS!), this is alarming. The tutorial on the bzr website referenced a command “bzr help topics”, which does not work.
So I’ll stick with my mercurial and darcs combination for now.
I announced the first version of a hg send extension yesterday as well. I think Mercurial is very close to having a working equivalent to darcs send.
bzr does support tagging now; it’s in version 0.15. It also supports creating emailable patches with meta-data (called ‘bundles’ — see the ‘bundle-revisions’ command).
Also, ‘bzr help topics’ works fine for me, giving a list of help topics available (bzr help gives me more on the selected topic).
Please research properly, before bashing a product.
0.15 is not released. I would not want to use some sort of development branch in production.
I am running the latest version in Debian sid.
$ bzr help topics
bzr: ERROR: unknown command “topics”
Nothing in the bundle-revisions command actually emails anything. This would leave it to an extra step, which was exactly my point. bzr doesn’t email anything. The mere fact that it generates an object that I *could* email is not my gripe. My gripe is that emailing isn’t integrated.
So, I stand by my comments. If bzr develops more features in future releases, I can look at it again then.
> 0.15 is not released. I would not want to use some sort of development branch in production.
> I am running the latest version in Debian sid.
Please tell me you’re joking.
Please.
I beg of you.
Scott Balneaves
I can’t also decide between git and hg, and I am also looking at every new bzr release, because I am very excited about that as well.
But I think the Mercurial Folks are way ahead and so is hg.
Interesting articles though.
I think you wanted ‘git format-patch master’
Nope, that generates no output at all.
See what I mean? ;-)
The bzr version in [b]sid[/b] is simply [b]ancient[/b] — latest release is 0.14 while sid still has 0.11. Bzr homepage will have more recent .deb.
Bzr 0.15 is currently release candidate, so it should be out in few days.
I have to say though, that while I used bzr for some time, I ended up liking the way git does branching and taggin more than the bzr way, though the bzr way is easier to learn.
Yes, the version of bzr in sid is pretty old; I uploaded it back in Oct. However, it’s not *that* old; bzr only recently added support for tags.
0.14 is in experimental, if you’d prefer to use something more up-to-date. Personally, I use git all of the time now. The interface infuriates me (and they just changed the branching interface and actually made it *harder* to use), but it’s quick, can handle kernel-sized trees, and gets the job done without causing my laptop to fall over.
John Goerzen recently posted about Git, Mercurial and Bzr that I found interesting, especially since I used to be in the hg camp, but have been gradually using git more and more, even to the point making minor improvements to the git documentation and writing the git mergetool, since being able to automatically fire up a graphical merge tool was one of the features which I missed from hg. So while I haven’t yet converted the primary SCM repository for e2fsprogs to use git (yet), I’ve reached an opposite concolusion from John, and yet, I can’t really argue with his observations.
The main reason why I’ve come out in favor of git is that I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has “more legs” than hg,
Bzr’s bundles are actually far superior to anything git does. You can email a bundle and it’s exactly equivalent to someone doing a merge from your repo, all metadata is included etc.
Git has a git-bundle command that does the same thing. Although it’s not limited to email, you can use it for any method of disconnected replication (cd/dvd/email etc).
I come from git camp, so please forgive me my bias.
WRT documentation, I think it is getting better. Nevertheless documentation looks like written by developers and experienced users, who _know_ where to find everything.
To export current branch as series of patches I would use (assuming that branch is based on ‘master’ branch, and we are on given branch) “git format-patch -n master..HEAD” (meaning: everything in current branch that is not [available from] master).
As to “darcs send” equivalent… in my opinion it is better to separate the ‘bundle’ generation from actual transport. Git has from almost the beginning git-format-patch and git-send-email / git-imap-send to send patches (for review), and lately it has git-bundle for disconnected replication (sneakernet, email).
As to being overly complicated: every powerfull tool has to be complicated.
I find ideas behind git very sound and clear (ideas of branches, tags, commit objects).
every powerful tool has to be complicated? i always find it very challenging to make a tool simple to use.
hg, and git are not examples of much brainwork in simplicity. while darcs is imo.
One of the things that makes me keep choosing KDE over GNOME is what was once said of KDE — that it’s a “desktop for grown-ups”. i.e., it’s not about having the latest cool color scheme or transparent terminals (except in the incomplete 4.0 release)… instead, it’s practical, useful, boring for the most part. But it gets work done. Quickly. When it comes to features, most of them are the intuitive things you HOPE your desktop will do when you’re actually using it and try something thinking, “you know, it’d really save me some hassle if I could just drag this here and the desktop knew what I wanted” or things like that.
For me, bzr is the same. It’s not exciting. It’s practical and predicatable. It’s version control for grown-ups who don’t care about quilts and storage methods, but DO need powerful features to just work so they can get things done.
I think the formula you wanted is
git format-patch $(git rev-list HEAD | tail -1)