From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Prefer Mercurial instead of git Date: Sun, 05 Jan 2014 21:17:14 +0900 Message-ID: <8738l2k4hh.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1388785952.11337.16.camel@Iris> <874n5k12ft.fsf@fencepost.gnu.org> <1388841220.11337.21.camel@Iris> <87bnzrzuzp.fsf@fencepost.gnu.org> <1388846441.11337.25.camel@Iris> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1388924252 4570 80.91.229.3 (5 Jan 2014 12:17:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Jan 2014 12:17:32 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: Jordi =?utf-8?Q?Guti=C3=A9rrez?= Hermoso Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 05 13:17:39 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VzmeA-0002vl-8c for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 13:17:38 +0100 Original-Received: from localhost ([::1]:57614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzme9-0008L4-78 for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 07:17:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzme1-0008Kz-C2 for emacs-devel@gnu.org; Sun, 05 Jan 2014 07:17:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vzmdv-0000FK-T3 for emacs-devel@gnu.org; Sun, 05 Jan 2014 07:17:29 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:43994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzmdp-00009u-Q2; Sun, 05 Jan 2014 07:17:18 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 21FCD970A32; Sun, 5 Jan 2014 21:17:15 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 12B9E1A2E7D; Sun, 5 Jan 2014 21:17:15 +0900 (JST) In-Reply-To: <1388846441.11337.25.camel@Iris> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167359 Archived-At: Jordi Guti=C3=A9rrez Hermoso writes: > I don't think Stephen's a particular expert in this I don't either. But since I'm not an expert, why listen to me? Listen to Barry Warsaw and Karl Fogel, who invited me to coauthor, instead: http://www.python.org/doc/peps/pep-0374/ http://www.emacswiki.org/BzrForEmacsDevs And to get David K to recommend me given how often we've been at each others' throats over the decades is a pretty good trick, one I'm proud of. > And I think Mercurial is a good choice, and I will choose it again, > and again. Technically, it is a good choice. I'm not unhappy with it for XEmacs development, although if things were moving as fast as they do in Emacs I might sing a different tune. Technically Bazaar was a good choice. As it turned out, the Bazaar developers were very good at fixing technical problems, including using different or even new algorithms when necessary. But it then turned out that once they weren't paid to do Bazaar, they stopped entirely. I didn't expect that, and it kills the deal, since there remain serious technical problems that affect some users (eg, network performance). Nevertheless, as ESR and DAK have been at pains to point out, the problem with Mercurial, like the problem with Bazaar, isn't technical. 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). 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.) Mercurial's supporting applications don't seem to improve as quickly (at least, not those distributed with Mercurial, cf. gitk vs. hg view). So git is clearly winning the popularity contest, both in general and on emacs-devel. 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. Mercurial's big advantage is that it's more comfortable for people who are already used to CVS or Subversion and never want to think about VC. For many Emacs developers, that is an attraction. It's not hard to use git that way, though -- it's just that if you ask people who use git's unique capabilities, they won't tell you about it :-/. But like Bazaar, it's hard to see Mercurial as a starting point for future evolution. As applied to programming, VC is an editing task, really. If developing new ways of applying editing technology is what Emacs is about, serious consideration should be given to giving up comfort for a while. 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. (Creating a "patch algebra" for that would be harder; it would have to involve a subfile type so that files become composite, just as trees are in current git -- but creating the subfile type is trivial in git, and the submodule kludge suggests that extending to a patch algebra might not be as hard as you'd think -- git's data structures are remarkably flexible. Add Emacs Lisp for creating new patch =3D=3D autoedit types and wow, you might have something new, bright! shiny!) 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". Nothing wrong with that -- as long as they save their opinions for their own workflows. Micro-commits, DAG compression, and even the much-maligned rebase all have their place in other workflows. Of course, as someone who frequently uses rebase, micro-commits, and similar techniques in my own workflows, I'm biased. 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).