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: resolving ambiguity in action stamps Date: Sun, 14 Sep 2014 17:59:18 +0200 Organization: Organization?!? Message-ID: <878ulmry5l.fsf@fencepost.gnu.org> References: <87wq9841zx.fsf@uwakimon.sk.tsukuba.ac.jp> <20140913053525.GA15582@thyrsus.com> <87tx4c3t4k.fsf@uwakimon.sk.tsukuba.ac.jp> <20140913.092630.2301242291023129455.hanche@math.ntnu.no> <20140913105058.GA16776@thyrsus.com> <87r3ze4pw6.fsf@uwakimon.sk.tsukuba.ac.jp> <20140914105531.GA30576@thyrsus.com> <87egve49d9.fsf@uwakimon.sk.tsukuba.ac.jp> <20140914142117.GA935@thyrsus.com> <878ulm434v.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410710411 28225 80.91.229.3 (14 Sep 2014 16:00:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2014 16:00:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 14 18:00: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 1XTCDb-0000Va-MY for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 18:00:03 +0200 Original-Received: from localhost ([::1]:55103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTCDa-0004qG-Bf for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 12:00:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTCDI-0004kw-6S for emacs-devel@gnu.org; Sun, 14 Sep 2014 11:59:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTCDC-0006L2-9I for emacs-devel@gnu.org; Sun, 14 Sep 2014 11:59:44 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:36943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTCDC-0006Ky-2b for emacs-devel@gnu.org; Sun, 14 Sep 2014 11:59:38 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XTCDA-0000Mi-VG for emacs-devel@gnu.org; Sun, 14 Sep 2014 17:59:36 +0200 Original-Received: from x2f4a4fb.dyn.telefonica.de ([2.244.164.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Sep 2014 17:59:36 +0200 Original-Received: from dak by x2f4a4fb.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Sep 2014 17:59:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 33 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f4a4fb.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.4.50 (gnu/linux) Cancel-Lock: sha1:DI38l9wBXNv6oF1Vf6DqApKDyJE= 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:174292 Archived-At: "Stephen J. Turnbull" writes: > Eric S. Raymond writes: > > > It is still a technical fact that no git translation containing SHA1s > > can be built without passing through a VCS-independent representation > > of commit refs on the way. > > Fact!? I would use the bzr revid, and insert the revid, SHA1 pair > after I commit each new revision in git on Pass 1. What am I missing? > (Read your next paragraph and my reply first!) > > > Yeah, that'd be nice, if a functional equivalent of filter-branch > > could do the job at all by itself. No chance of that: see above > > about hash mixing. > > Of course my proposal needs a database that's writable, and must > update the bzr id to git id mapping every time filter-branch makes a > new commit. It's not trivial, but it's not going to be hard. Unless > you think there are Emacs developers smart enough to refer to bugs > that will occur in as-yet uncommitted revisions by revid? When revisions are numbered consecutively, that can actually happen. When creating a commit in some other project referencing an issue number, I am sometimes lazy enough to create the full commit message before the issue even exists. Depending on how many people are active on some project, this may require doubling up. But with Bzr revisions, referencing as-yet uncommitted revisions is slightly more believable than with Git. -- David Kastrup