bzr merge-directive

generates a bundle containing all the new changes compared to the parent branch. In the typical use of branching to implement a feature or fix which is then integrated back in, you don’t need to give any other arguments.

People often save this to a file and then post through their regular mail agent, but you can also send it directly with –mail-to.

I believe git added support for this after a crossposted thread which discussed how well it worked in Bazaar.

If you use bundle repositories with hg (which are again just a different representation of the same data), you can shrink the size of current e2fsprogs repo to 7948K, though using it is only partly wired to the UI:

cd e2fsprogs
hg bundle –base null ../e2fsprogs.hg
hg init ../dummy
cd ../dummy
hg -R ../e2fsprogs.hs

One “small” downside is, that the bundle repository is read-only, but that doesn’t matter if we’re just comparing repository sizes.

The trouble with “hg strip” is that it can only strip the most recent revisions that are closest to the tip. If you create internal branches in hg, and then later commit or pull new revisions on top of your changes, and then you want to drop the internal drop, I believe right now the only way to do it require rewriting the whole repository.

If you create the directory .git/rr-cache, then if you have a long-lived branch where you are developing some feature that isn’t quite ready for mainline, but while you are developing it, you are constantly pulling and merging from the mainline, this can result in the same conflicts needing to be resolved over and over again. This is sometimes called “cross-cross merges”, and if the .git/rr-cache directory is created, git will remember how particular merge conflicts were resolved, and try to resolve them the same way in the future, automatically. More information about this can be found here.

Thanks as always for your feedback.

Regarding #1, I hg cloned your e2fsprogs repo and get 15,676K in Mercurial. I wonder if your repo hasn’t yet switched to hg’s revlog-NG? Still bigger than git, but about half the difference as before.

Regarding #6, the transplant extension does the rebase. hg strip can prune of unwanted revisions out of hg trees as well.

2. Simplicity — no contest. Hg is simpler, but part of this is it has less functionality. Still, if it has the functionality you care about, the lack of extra commands is a virtue.

3. “git bundle” will be in git 1.5.1, which will be releases shortly; git 1.5.1-rc2 is quite stable, and is available already today.

4. “git mergetool” was written by yours truly, and will also be in git 1.5.1. It has pretty much all of the functionality of hg’s merge integration, with the exception of MacOS’s opendiff/FileMerge, for which someone has submitted patches but I haven’t had a chance to download MacOS’s developers tool so I can test the patch.

5. The mercurial community is probably more receptive to ideas, yes. The active community on the git list seems slightly larger, but that’s hard to judge. The git list is definitely more active. As far as being receptive to new ideas, part of it is that Linus has pretty strong ideas over what will work and not with SCM systems. If you try to do something that doesn’t agree with his philosphy, he isn’t afraid to say you’re wrong. The thing is, very often he’s right, although sometimes I wish he would do so with a tad bit more diplomacy.

6. Does mercurial have rebase functionality at all? I didn’t think it did. You can pull a branch and merge it into tip of another branch, and it won’t lose the history, yes, but you can do the exact same thing with git. “git rebase” is an option, but you don’t have to use it.

I’ll note that sometimes trashing history is specifically one of the things that various development processes actually want. For example, requests have come from more than one project to both mercurial and git that they implement “bk collapse”, which takes a series of commits, and makes them disappear into a single commit. It turns out it’s much harder to implement this in hg, because of how it stores its file-level revision information. Fundamentally, hg makes it harder to drop changesets, which can either be viewed as a feature or a bug. Myself, I like to be able to do development in internal branches, and then drop them later on without penalty, and that’s something which in the hg model is best done by cloning an entire separate repository. But everyone’s workflow is different….

Clone OpenSolaris. Do “hg log” and find the last two changeset ids. Now do “hg up ” to move between them.

That’s around 5 seconds even if only one file has changed. That doesn’t seem fast to me. Git is much quicker.

Other than that Mercurial looks really promising.

Again great!

Darcs is the clear winner in this one. I wonder why is it the only one vcs that does not use the ‘tree of changesets’, but the superb ‘pool of changesets’.