From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: resolving ambiguity in action stamps Date: Sat, 13 Sep 2014 19:43:31 +0700 Message-ID: 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> 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 1410612236 21113 80.91.229.3 (13 Sep 2014 12:43:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Sep 2014 12:43:56 +0000 (UTC) Cc: Harald Hanche-Olsen , Emacs developers To: Eric Raymond Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 13 14:43:49 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 1XSmg7-0005DK-B0 for ged-emacs-devel@m.gmane.org; Sat, 13 Sep 2014 14:43:47 +0200 Original-Received: from localhost ([::1]:49593 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSmg6-0005Gm-T2 for ged-emacs-devel@m.gmane.org; Sat, 13 Sep 2014 08:43:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSmft-0005Gg-Ui for emacs-devel@gnu.org; Sat, 13 Sep 2014 08:43:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSmfs-0004lw-QL for emacs-devel@gnu.org; Sat, 13 Sep 2014 08:43:33 -0400 Original-Received: from mail-ig0-x231.google.com ([2607:f8b0:4001:c05::231]:64584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSmfs-0004lo-Kq for emacs-devel@gnu.org; Sat, 13 Sep 2014 08:43:32 -0400 Original-Received: by mail-ig0-f177.google.com with SMTP id h15so1892378igd.4 for ; Sat, 13 Sep 2014 05:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oWpXlX6glxRftyj+5LeetQ0Nksx/M7bwNVRoEJFcfSQ=; b=i7yipvIt+iYesUqB073oPaT3PJ500PVKhI2Qw0WuOFGvePaIN3PfaPRo0Lu38CT6SU QoqykK01pSH0Mf7sWSrx+LTU4OzZVap02ysNZcq73nlE/YkyZRh88q4DNZl30dqbhInk oAGgHYvEHQA0CiYDjSLJeEx0iC2Ua/coR6oGazdHWESlGoBWE09PxoXZvwh+yx+w5NT8 sEDW7oiNlKBZEbEZfDmsju8IWlXA5AR8ytJ/EhsCVtYFfQSnV+qvjiUVenP1CDt6zyo9 IGqhwQ0bzn86Q3klaVBeo0nR31ynRmg3AQsXAmg59QIwaN1ePt0+rfofydszEO1VzV4D caaA== X-Received: by 10.50.88.98 with SMTP id bf2mr9637958igb.11.1410612212011; Sat, 13 Sep 2014 05:43:32 -0700 (PDT) Original-Received: by 10.107.164.194 with HTTP; Sat, 13 Sep 2014 05:43:31 -0700 (PDT) In-Reply-To: <20140913105058.GA16776@thyrsus.com> X-Google-Sender-Auth: fJ1b9QpwDSesNtykmv62u4ACIac X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::231 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:174270 Archived-At: On Sat, Sep 13, 2014 at 5:50 PM, Eric S. Raymond wrote: > Both of Harald's objections are, alas, sound. In particular, the > branch total ordering is not useful if any commit can arbitrarily > permute it. > > The hash of the branch's *root* node would be better. But that still > leaves the two of the three problems unsolved. One of them being =E2=80=9CHow do you define the root node of a branch?=E2= =80=9D. * You cannot mean the commit that is most distant one reachable from the branch tip, because that root (the =E2=80=9CBig Bang=E2=80=9D of the re= pository) is often common to all branches. * Do you mean the most distant commit that is reachable from this branch and unreachable from other branch tips? Then this is invalidated by creating a new branch tip. If two branch tips point to the same commit, then, under this definition, they have no root at all. No, if we want a mathematically sound and (mostly) implementation-agnostic way to refer to commits, then it has to: * be invariant under the operations that do not modify the graph =E2=80=94 branch tip and tag creation, deletion, renaming, resetting, pushing/fetching; * be invariant under the operations that are commonly performed on the graph during normal repository use (creating new commits, pushing and fetching); * (optional but highly desired) be well-behaved under less common operations (cherry-picking, rebasing, force-push). An author + authoring timestamp combination is in my opinion the closest thing in Git. It leaves ambiguity when a commit is cherry-picked or rebased, but: * This ambiguity may be resolved by tracing reachability from the referring commit. It should be a rare situation when more than one instance of the same rebased commit are reachable from a single descendant/referrer. ** Under that heuristic, rebasing the referrer over to the branch containing a different instance of the referree will =E2=80=9Cfix up=E2=80= =9D the reference to point to that instance. I actually see this as a good thing, e.g. when both commits are rebased in a single rebase operation. ** However, on certain occasions, one may want to refer to a commit on a different branch, e.g. when cherry-picking, add a reference to the original commit. I do not have a solution here, apart from =E2=80=9Cdon=E2= =80=99t do that=E2=80=9D. One could suggest ordering the commits having the same author+timestamp by their commit timestamp (or in fact any other property), and appending the numeric position according to that order as a disambiguator. This will break if a reference is made without knowledge of the combined global set of instances of the commit referred to =E2=80=94 uniting different subsets during fetch or push will change the positions and invalidate references. I suggest that, if it is desirable to be able to unambiguously refer to commits in a rebaseful graph, the 4-tuple will provide a good approximation. In practice, I believe will be precise enough for human software archaeologists.