From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jordi =?ISO-8859-1?Q?Guti=E9rrez?= Hermoso Newsgroups: gmane.emacs.devel Subject: Re: preferring mercurial Date: Fri, 10 Jan 2014 10:03:48 -0500 Message-ID: <1389366228.5784.14.camel@Iris> References: <3905544.suqMZffgM5@descartes> <874n5d6whz.fsf@gaia.iap.fr> <87iottf4fe.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1389366236 31045 80.91.229.3 (10 Jan 2014 15:03:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jan 2014 15:03:56 +0000 (UTC) Cc: =?ISO-8859-1?Q?R=FCdiger?= Sonderfeld , Neal Becker , =?ISO-8859-1?Q?Fran=E7ois?= Orieux , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 10 16:04: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 1W1dcv-0001b3-PA for ged-emacs-devel@m.gmane.org; Fri, 10 Jan 2014 16:04:02 +0100 Original-Received: from localhost ([::1]:57326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1dcv-0007WM-Co for ged-emacs-devel@m.gmane.org; Fri, 10 Jan 2014 10:04:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1dco-0007V5-FK for emacs-devel@gnu.org; Fri, 10 Jan 2014 10:03:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1dcj-0001tJ-Ul for emacs-devel@gnu.org; Fri, 10 Jan 2014 10:03:54 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1dcj-0001tD-SA for emacs-devel@gnu.org; Fri, 10 Jan 2014 10:03:49 -0500 Original-Received: from beast.bic.mni.mcgill.ca ([132.206.178.199]:51791 helo=[IPv6:::1]) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1W1dcj-0006yE-EU; Fri, 10 Jan 2014 10:03:49 -0500 In-Reply-To: <87iottf4fe.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Evolution 3.4.4-3 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:168010 Archived-At: On Fri, 2014-01-10 at 02:31 +0900, Stephen J. Turnbull wrote: > Fran=C3=A7ois Orieux writes: >=20 > > My resume of all the posts I have read is that git and hg are > > technically equivalent. >=20 > AFAICS they are very much *not* technically equivalent. They may be > equal in power, especially at the UI level, but git exposes a much > cleaner interface to the internal model of blobs (file content), > trees (file directories), and commits *to the user*.=20 To me this seems like a *bad* thing. You wouldn't want to write mallocs in order to use Emacs just because part of Emacs is written in C. That would not make you feel more productive. User interfaces are a good thing. It's ok to have hackable internals, but it's not ok to expose them by default. Granted, with the likes of legit, magit, or git-flow, then git really does get a UI, so perhaps you'll just say that git's defaults are not for me. Furthermore, hg's internal data structures aren't that hard to understand either. Commit -> tree -> blob -> ref, meet changelog -> manifest -> filelog -> revlog. This is a good introduction to hg's internals: http://hgbook.red-bean.com/read/behind-the-scenes.html They're both actually quite similar, trees are like manifests, blobs are like revlogs. A testament to how similar is that it's actually possible for Kiln Harmony to exist: a bridge between git and hg at the *data structures* level. > This means that git is more hackable: you can script it with shell, > you can script it with Python, you can script it with Emacs Lisp, or > you can write C. You can do any of these with hg, and you have your choice of C (hg's commandserver), Python ("import mercurial"; it's just another Python library), or bash or any other language (parsing hg's stdout, guaranteed to be parseable forever). The way magit is written, just by piping to and from git is exactly the way that it could be written for hg. > I don't know about Mercurial, haven't looked at its internals. Neither have I in detail until recently, in order to understand why it was faster than git. > Git invites you to play with the DAG, just as Lisp invites you to > play with lists. There's lots of DAG playing in hg too. Please recall my past message to you in which I outlined the hg commands for DAG-playing. > Nothing has more respect for history than git. This isn't very respectful of history: http://www.infoq.com/news/2013/11/use-the-force/ It took a lot of work to fix this problem: http://jenkins-ci.org/content/summary-report-git-repository-disruption-= incident-nov-10th > That's why git doesn't have backups (the way hg and bzr > save bundles if you do a "commit --amend" or a "strip") This is a quibble. One stores backups on the DAG and you have to dig through the reflog to get them. Another stores backups in .hg/strip-backups and you have to use hg incoming to dig through them. It's just a UI difference. The biggest difference is that by default git deletes it automatically after a longish time, but hg doesn't. With hg's evolve, however, you get something much better than either strip bundles or unreferenced commits: safe collaborative edition of history that knows how to propagate across clones. No more "git push --force"! > History isn't *changed*, it is recreated Same in hg. New history means new hashes. Old history is still lying around. > and the original history remains accessible to the user. Sort of. Depends on what you mean by "accessible". To an unexperienced user, either of git or hg, rewritten history can appear to be lost until they learn the proper incantations to recover it. This is why hg disables history edition by default, analogous to how Emacs disables some commands by default. It's just a matter of unmuzzling them both if you want to use those features. > AFAIK hg and bzr *do* destroy history when they perform operations > like commit --amend, strip, and rebase. I hope I helped you to know better now. Lastly, let me say that git has its uses, but it also has some fundamental flaws, and there's still plenty of room for friendly competition. :-) - Jordi G. H.