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: preferring mercurial Date: Sun, 12 Jan 2014 00:55:38 +0900 Message-ID: <871u0efr7p.fsf@uwakimon.sk.tsukuba.ac.jp> References: <3905544.suqMZffgM5@descartes> <874n5d6whz.fsf@gaia.iap.fr> <87iottf4fe.fsf@uwakimon.sk.tsukuba.ac.jp> <1389366228.5784.14.camel@Iris> <8738kvfxtj.fsf@uwakimon.sk.tsukuba.ac.jp> <1389383753.5784.24.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 1389455818 7997 80.91.229.3 (11 Jan 2014 15:56:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 15:56:58 +0000 (UTC) Cc: =?utf-8?Q?R=C3=BCdiger?= Sonderfeld , Neal Becker , =?utf-8?Q?Fran=C3=A7ois?= Orieux , 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 Sat Jan 11 16:57:04 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 1W20vn-0008JL-M5 for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 16:57:03 +0100 Original-Received: from localhost ([::1]:34492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W20vn-0000qX-BK for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 10:57:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W20ve-0000pS-3L for emacs-devel@gnu.org; Sat, 11 Jan 2014 10:57:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W20vW-0008S7-On for emacs-devel@gnu.org; Sat, 11 Jan 2014 10:56:54 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:51747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W20vW-00083z-7F for emacs-devel@gnu.org; Sat, 11 Jan 2014 10:56:46 -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 62E559709A5; Sun, 12 Jan 2014 00:55:38 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5501F1A2E82; Sun, 12 Jan 2014 00:55:38 +0900 (JST) In-Reply-To: <1389383753.5784.24.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:168081 Archived-At: Jordi Guti=C3=A9rrez Hermoso writes: > In hg the problem is much easier to solve without server-side access: > just push another commit closing-branch commit on the extra head that > you don't want to keep working on. You don't seem to understand what the problem is. Consider an hg repo with 100 bookmarks, all of which suddenly point to completely different places -- or worse, places that at a glance look like where you should be but in fact are different. Now figure out how to re-associate the 100 bookmarks with the correct dangling heads. Why is this easier in hg than it would be in git? > > Unfortunately, no. The actual behavior of hg is indeed immediately > > destructive in some cases, unlike git. >=20 > git has immediately destructive operations too, for example the > "git reset HEAD --hard" that everyone blindly memorises (who really > can keep all of the kinds of resets straight?) I haven't had any trouble. > will destroy all unstaged changes. Indeed. But unstaged changes aren't history yet, by definition. (And in git staged changes are: there will be objects to match in the object database.) Anyway, my point has never been that git doesn't have issues, even design bugs such as the lockless gc. The point is that as far as DAG manipulations go, it's easy to reason about what git will do and where commits will be if they get lost. Even about GC -- if multiple GC processes are running, you're going to get corruption. :-P But hg ... for example, don't you think it's kinda gross that hg (including Evolve) has 3 different backup mechanisms that you've mentioned so far (.orig, strip backup, hidden obsolete commit)? And there may be variations on some of them (does hg have a "git-stash" equivalent? which format does it use? are strip backups =3D=3D bundles =3D= =3D mq patches? if so, why the proliferation of names? if not, how do they differ?) Not to forget that Mercurial has 2.5 kinds of branch structure: bookmarks, named branches, and the special named branch "default".) In the case of git, you just branch. (OK historically there was quilt, but quilt really prexisted even bitkeeper.) And there's only one kind of branch structure: the transitive closure of the parent relation for a commit. A stash is a specialized branch. The reflog is a collection of specialized branches with algorithmically generated names. A tag is more or less a closed branch. Tracking branches help you keep your upstream and downstream straight. Doing something dangerous? Tag or branch and work on that -- and you needn't even fear gc. **************** I know there are a lot of people who want to blindly memorize recipes and never think about their tools. Mercurial is great for them. But every time I say "what about ..." you respond, "oh, there's a hack for that" (and in a VCS, keeping diffs as a backup is definitely a hack). Proliferation of special hacks makes it hard to think about such tools. But I think that Emacs users by and large *do* think about their tools. Sure, Eli dislikes git and has refused to work on Bazaar. But that's more or less an accident: I know from other MLs that he works on DJGPP and gdb and AFAIK neither is his job -- he could let other people do that, too. But he doesn't, he contributes. Thing is, there are a lot of folks in Emacs who *do* care to think about VCS. Karl Fogel wrote one, for heaven's sake. ESR clearly thinks about VCS a lot (to the extent that he still considers himself maintainer of vc.el). Andreas obviously knows git inside out. DAK has threatened to contribute patches to git. And that's just off the top of my head. You may not see a difference between the design of git and hg, but I do, and I think Emacs developers are more likely to make Emacs-relevant contributions to git's ecosystem than to hg's.