From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: preferring mercurial Date: Sat, 11 Jan 2014 17:37:00 +0100 Organization: Organization?!? Message-ID: <8738kuh3v7.fsf@fencepost.gnu.org> 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> <871u0efr7p.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1389458260 372 80.91.229.3 (11 Jan 2014 16:37:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 16:37:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 11 17:37:46 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 1W21ZC-0000iq-3T for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 17:37:46 +0100 Original-Received: from localhost ([::1]:34600 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W21ZB-0001UB-Nt for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 11:37:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W21Yp-00015M-16 for emacs-devel@gnu.org; Sat, 11 Jan 2014 11:37:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W21Yi-0001QI-Oh for emacs-devel@gnu.org; Sat, 11 Jan 2014 11:37:22 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:36254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W21Yi-0001Pz-In for emacs-devel@gnu.org; Sat, 11 Jan 2014 11:37:16 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W21Yh-0000HI-Uu for emacs-devel@gnu.org; Sat, 11 Jan 2014 17:37:15 +0100 Original-Received: from x2f3cf5e.dyn.telefonica.de ([2.243.207.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Jan 2014 17:37:15 +0100 Original-Received: from dak by x2f3cf5e.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 11 Jan 2014 17:37:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f3cf5e.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:Khs6rVluflw32GK774TrQ0JyayQ= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:168087 Archived-At: "Stephen J. Turnbull" writes: > Jordi Gutiérrez 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. > > > > 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.) Well, if they have not entered the reflog yet, they will be pretty hard to dig up. It's like handing someone a disk and saying "don't worry, all the data is still there, only the inodes have been lost". If we are talking about something like a private Bitcoin key (small and very precious, hopefully identifiable), digging for it will be worth the cost. > DAK has threatened to contribute patches to git. Oh, I did in the past speed up the diffing algorithm and made it use less memory, so it's not an idle threat. With regard to my threat of working on "git blame", I've got non-working code doing most of the part. I have just decided that the whole algorithm does the wrong things in the wrong order, so fixing the "remaining" bugs will lead to badly maintainable code of the "don't touch this, it seems to work right now" variety. So I am doing the core algorithm and data structures from scratch, and that takes longer. The problem is to stop somewhere before I rewrite all of git's library... But then I suffer from the "I can do better than _that_" phenomenon pretty much every time I look too close at software written by somebody else. And if you don't manage to keep yourself confined to messing with about a man*month's worth of messy code, you don't get anywhere... -- David Kastrup