Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sun, 2014-01-05 at 21:17 +0900, Stephen J. Turnbull wrote:
> Jordi Gutiérrez Hermoso writes:

>  > And I think Mercurial is a good choice, and I will choose it again,
>  > and again.
> 

> The problem is that Mercurial isn't git. Git definitely is the
> leader now. Git is "cool". Git is more flexible (neither Mercurial
> nor Bazaar can support workflows that use colocated branches
> heavily).

Huh, bookmarks? We use "collocated branches" heavily in GNU Octave
during our GSoC experience, and it worked just fine. Our GSoC students
were each working on their bookmark, and we've pulled their code into
mainline when it was ready. Otherwise we typically use named branches,
since it's easier for core devs to just watch at most 2 or 3 branches
at the same time over a long period of time. Both branching types have
their uses.

> Git has more growth potential: new techniques for manipulating DAGs
> are developed in and for git. (They can't be developed *in*
> Mercurial or Bazaar command language, you have to go to Python level
> to develop useful new features.)

This isn't true, Mercurial's API is its CLI (so is git's, really, but
git is bold enough to also call it a UI, which I don't think it
deserves). Its CLI is what is promised to remain stable, and you can
develop plenty of tools with its CLI only, and people do. We automate
workflows by reading and parsing its stdout. This is, for example, how
Mercurial's most popular front-end that you somehow failed to mention
works: TortoiseHg.

We could adapt magit to use hg exactly the same way. Every git command
it writes has an hg equivalent. For example, last time I checked,
magit stages hunks by creating a patch in memory and sending it to
git's stdin, this can be done in hg with something such as

    cat patch | hg qimport --name staging-area -

Writing hg extensions in Python is just a nicer choice for some
things if you happen to already like Python.

> Mercurial's supporting applications don't seem to improve as quickly
> (at least, not those distributed with Mercurial, cf. gitk vs. hg
> view).

Nobody cares that TortoiseHg isn't distributed with hg, since for many
interested people, TortoiseHg bundles hg.

> So git is clearly winning the popularity contest, both in general
> and on emacs-devel.

I don't get this argument. Windows and Mac OS X are also more popular;
does this mean we shouldn't use any other OS because all of the cool
games are almost exclusively developed on Windows?

And Mercurial, despite being less popular, *does* get a lot of toys
developed for it too. One that I like that replaces my most frequent
usage of magit is crecord: interactively select hunks for committing.

> I actually see two features that git doesn't provide (and I don't
> know how git would provide them robustly) in Bazaar (bound branches
> and mainline-respecting operations). I don't see any in Mercurial.

I'm surprised. You've been using hg this long and you haven't seen any
new features? Here are a few of hg-only features that are really cool:

   * revsets: (hg help revsets) hg supports a really cool DSL for
     querying its history. It's very rich and easy to understand.
     There's very little syntax to memorise, since it's a language
     built on simple function calls. It's far richer than what you can
     get in gitrevisions(7) The resulting queries can be used anywhere
     in the CLI where a single revision can be used.

   * Evolve and phases: This git lecture,

      http://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase

     is pointless from a pure DVCS point of view. There is nothing
     that should stop us from "rebasing" as, git calls all DAG
     modifications, upstream source. In Mercurial, it is possible to
     collaboratively edit history ("rebase", in git parlance). There
     are two tools in place for this, phases, which indicate which
     commits are "safe" to collaboratively edit, and Evolve, which
     brings forth some tools for automatically handling the conflicts
     that ensue. In Mercurial, commits carry around extra metadata
     that propagates across clones and indicates whether this commit
     has been modified upstream or not. Evolve uses this metadata for
     automatically fixing any instability that is based on the commits
     that upstream has modified.

   * Instant web interface: This one is more well-known. You can do
     "hg serve" at any time to instantly serve a particular repo over
     the web. This is supposed to be a lightweight server, so it's not
     suited to be used alone without nginx or Apache or whatever, but
     it's good enough for a quick setup between friends. The instant
     web interface is featureful enough to do most read-only hg
     operations plus it also allows pushing to the repo it's serving
     from.

There are others that are a little less impressive but just present a
nicer interface: hg's templating engine, which is both used for
presenting the hg log and for creating custom hgweb designs, being
able to push to any repo (i.e. no need for a separate bare repo type),
hg outgoing and incoming for seeing what commits will be shared before
doing any actual sharing.

My point here is that Mercurial is not short of innovation, apparently
only short of publicity. So here is some publicity.

> Eg, it's hard to see how Mercurial or Bazaar could directly support
> a Darcs-like patch type, but in git it's simple: just a pair of
> SHA1s.

I have only briefly skimmed Darcs' theory of patches. If you're
patient enough to explain to me what you hope to accomplish by
emulating it, I might enjoy thinking about how to implement it in hg.
Since hg has very similar architecture to git and you say this is easy
in git, I am certain this is feasible.

> Also, people who think in terms of "commit" and "update" being
> heavyweight (network) operations tend to insist on associating
> commits with development milestones. They deprecate git's
> DAG-traversing as useless and DAG-editing as "history modification".

No, hg has a lot of ability to modify history or traverse the DAG, as
you call it.

> Of course, as someone who frequently uses rebase, micro-commits, and
> similar techniques in my own workflows, I'm biased.

Apparently you're not using them in Mercurial? 

    hg commit --amend
    hg histedit -r .~3
    hg update -r @
    hg rebase -b myseries
    hg crecord

Do you know what these tools do? Is there a reason why you don't use
them, if you really are not?

> But between the growth possibilities inherent in git's simpler, more
> extensible architecture, and current workflows that are difficult to
> impossible to emulate with other VCSes, I think git is both
> technically and by popularity the obvious choice (if Emacs is going
> to switch VCSes).

Of course I don't dispute that git is more popular, but I do contend
that hg is not as small as bzr, and its development status is much
more healthy than bzr's. It's also not as obscure as bzr, and given
the amount of money that is being pumped into it by several commercial
entities,

    http://mercurial.selenic.com/sponsors/

fears of something like what Canonical did to bzr seem unfounded to
me.

Mercurial is a good choice, despite being less popular than git.

- Jordi G. H.