

Mercurial 1.1 DVCS Released - gecko
http://selenic.com/pipermail/mercurial/2008-December/022670.html
You can see a full list of the new features at http://www.selenic.com/mercurial/wiki/index.cgi/WhatsNew. My favorites:<p>1. A real rebase command, rather than having to use quilt voodoo
 2. bookmarks, git-style lightweight local branches (though git users beware, though bookmarks and local branches have the same functionality, their semantics are radically different (and speaking as a Mercurial user, I prefer git's, but whatever))
 3. Much more Windows-friendly repository format (and improvements to case-folding systems in general)
 4. Vastly improved web interface<p>There's lots more, but having used the development version for the last several weeks, the above features are my favorites.
======
shutter
Cool. The changelog lists lots of updates; I'd be interested to hear from
those who have had more experience with Git as to whether this improves
Mercurial's stance versus Git.

~~~
gecko
So, disclaimer: I'm a Mercurial fan.

There are two big things git has traditionally done better than Mercurial:
lightweight branching, and rebasing. Both were possible in Mercurial using mq
(plus qguards, in the case of lightweight branching), but the experience was
rather clumsy. I didn't mind putting up with it, since, at the time the two
systems came out, Mercurial was markedly easier to use than git. But, over the
last year, git closed a lot of the usability gap, while Mercurial has held
almost completely still, and that's resulted in a lot of arguments that
Mercurial's time had passed, and git was the way to go.

The good news is that this release fully eliminates git's first advantage, and
either eliminates, eliminates and beats, or fails to address the second,
depending on where you're coming from. The easy news to process: the rebase
extension enables full git-style rebasing, end of story. You can do an
automatic pull and rebase via `hg pull --rebase`, if that's what you want, or
you can do more customized rebasing via `hg rebase`. So that's done, and,
based on my use in production environments, works very well.

Now, Mercurial 1.1 introduces real lightweight branching--no mq hackery--via
an extension called `bookmarks`, which ships with Mercurial. These provide
identical capabilities and benefits as git's local branches. The complicated
discussion we can have revolves around bookmark _semantics_. bookmarks, like
git branches, are basically "floating tags"--tags that mark a head in the
repo's DAG, and that move with that head as you issue additional commits. The
difference comes from the fact that bookmarks very directly expose what's
going on, whereas git's branch command hides what's going on behind what I
personally feel is a more intuitive UI. So, the argument is: is exposing
what's actually going on better, because it gives you more power; equivalent,
since the functionality provided is identical; or worse, because too much
implementation is exposed in interface. I personally need more time to sort
out preconceived bias of what micorbranching should look like, from the
bookmark extension in particular.

~~~
yummyfajitas
Ok, a question from a darcs guy who recently switched to hg:

What are the use cases for rebase and lightweight branching? I really don't
understand why I should prefer rebase to simply pull + merge. Also, is
lightweight branching just a performance hack, or is there more to it?

~~~
mechanical_fish
In git, a use case for rebase that I'm intimately familiar with is
interoperability with SVN. You can maintain a branch that's a mirror of an SVN
repository, but if you do any merging and then try to check the results into
SVN the result is a train wreck. In the somewhat acid words of the git-svn
manpage:

 _Running git-merge or git-pull is NOT recommended on a branch you plan to
dcommit from. Subversion does not represent merges in any reasonable or useful
fashion; so users using Subversion cannot see any merges you've made.
Furthermore, if you merge or pull from a git branch that is a mirror of an SVN
branch, dcommit may commit to the wrong branch._

The proper technique is to make a branch based on your SVN repo, make a bunch
of changes on the branch (using _svn rebase_ to keep your development branch
in sync with changes on the SVN master branch, and -- god help us -- diff-and-
patch if you have to merge in changes from some other git branch; this is your
penance for working on an SVN-hosted project), then commit the whole thing
back to SVN once you have it in shape. It sucks compared to true-blue git but
is still nicer than SVN, because (e.g.) you get things like...

... the other use case for rebase, _git-rebase --interactive_ , a.k.a. "take
the last N commits and let me reorder, combine, and edit them however I want."
I love this feature. See:

[http://blog.madism.org/index.php/2007/09/09/138-git-
awsome-n...](http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-
git-rebase-interactive)

For more useful ravings about git's features:

<http://tomayko.com/writings/the-thing-about-git>

~~~
gecko
I'm not going to try to sell you on Mercurial vs. git, mostly because I think
that argument is pointless, but just so you're aware, Mercurial also supports
reordering and combining patches via mq. And that's an area where I personally
feel that Mercurial's method actually makes more sense than git's, though
you're welcome to disagree.

[Edit: Oh, and: yes, that's a perfect example of where rebasing makes sense,
and is exactly the kind of rebase operation Mercurial now fully supports,
without any complicated patch wrangling.]

