From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: resolving ambiguity in action stamps Date: Sun, 14 Sep 2014 10:21:17 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20140914142117.GA935@thyrsus.com> 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> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1410704525 22838 80.91.229.3 (14 Sep 2014 14:22:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2014 14:22:05 +0000 (UTC) Cc: Harald Hanche-Olsen , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 14 16:22:00 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 1XTAgi-0004Y8-16 for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 16:22:00 +0200 Original-Received: from localhost ([::1]:54848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTAgh-0002u6-JK for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 10:21:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTAga-0002tz-An for emacs-devel@gnu.org; Sun, 14 Sep 2014 10:21:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTAgV-0001kO-Tm for emacs-devel@gnu.org; Sun, 14 Sep 2014 10:21:52 -0400 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:53439 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTAgV-0001kF-Q4 for emacs-devel@gnu.org; Sun, 14 Sep 2014 10:21:47 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 4F77F3807C7; Sun, 14 Sep 2014 10:21:17 -0400 (EDT) Content-Disposition: inline In-Reply-To: <87egve49d9.fsf@uwakimon.sk.tsukuba.ac.jp> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:174289 Archived-At: Stephen J. Turnbull : > Eric S. Raymond writes: > > > One is a genuinely funny gotcha. You can't get to git hashes > > without going through something semantically like my version stamps > > on the way! > > I disagree. Well, maybe you have some case, but haring off into bug bisection techniques doesn't make it. 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. This is because the SHA1-containing repo would have to be built one commit at a time in order for the correct target hashes to *exist* to be patched into whatever refers to them. That means the rewrite of the old commit refs has would need at some point to pass through a mapping of old refs to something that identifies a commit but cannot be a git hash *because the hash doesn't exist yet!* That's the gotcha. This is not limited to git: it would a general problem with hg or any other target VCS in which parent hashes are mixed into a commit's hash. I have a design sketch in my head for a tool (a filter on fast-import streams) to work around this problem, but it can't eliminate the need for a VCS-independent commit-ref format, only hide the fact that one was used during the move. > > The second problem is that it's not future-proof. Someday we might > > have to change VCSes again; git is the *fifth*, after RCS CVS Arch > > bzr. It would be unwise to assume that nobody will ever have a > > better idea. > > I don't. But if the new one can't run > > $VCS filter-branch --commit-filter ... > > as fast as git, I'd have serious doubts about the sanity of the > proponents. Even on a 200,000 commit repo, that's just not going to > take a ton of time, and only needs to be done once. 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. > > At that time it would be a Really Good Thing if as few of our commit > > refs as possible are opaque magic cookies > > Actually, I disagree. It would be a really good thing if they are > precise. Do you really want to put anybody through the trouble of > translating randomized format cookies, which may point to any of > several commits, again? Then revising their scripts every time a new > variant shows up? It has yet to be demonstrated that this is a problem in a real use case. And, actually, I already checked this; the Emacs history doesn't have any version-stamp collisions in actually referenced revisions. > Existence proof comes before characterization, please. I don't understand that. -- Eric S. Raymond