Re: Prefer Mercurial instead of git

From: Jordi Gutiérrez Hermoso Subject: Re: Prefer Mercurial instead of git Date: Sun, 05 Jan 2014 08:19:27 -0500

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.