From: Yuri Khan <yuri.v.khan@gmail.com>
To: Eric Raymond <esr@thyrsus.com>
Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>,
Emacs developers <emacs-devel@gnu.org>
Subject: Re: resolving ambiguity in action stamps
Date: Sat, 13 Sep 2014 19:43:31 +0700 [thread overview]
Message-ID: <CAP_d_8UZ7LMACmgrRAMbwmrw-T4QPgfN5n=B5x3OQ4GF0O4VFA@mail.gmail.com> (raw)
In-Reply-To: <20140913105058.GA16776@thyrsus.com>
On Sat, Sep 13, 2014 at 5:50 PM, Eric S. Raymond <esr@thyrsus.com> 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 “How do you define the root node of a branch?”.
* You cannot mean the commit that is most distant one reachable from
the branch tip, because that root (the “Big Bang” of the repository)
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 —
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 “fix up” 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 “don’t do
that”.
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 — 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 <author, authoring
timestamp, committer, commit timestamp> will provide a good
approximation.
In practice, I believe <author, authoring timestamp, optional part of
commit summary> will be precise enough for human software
archaeologists.
next prev parent reply other threads:[~2014-09-13 12:43 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 4:36 Everyone, please stop making my life more difficult Eric S. Raymond
2014-09-12 6:08 ` Eli Zaretskii
2014-09-12 9:55 ` Eric S. Raymond
2014-09-12 10:33 ` Eli Zaretskii
2014-09-12 10:49 ` Gregor Zattler
2014-09-12 13:05 ` Eli Zaretskii
2014-09-12 13:19 ` David Kastrup
2014-09-12 13:29 ` Eli Zaretskii
2014-09-12 13:55 ` Andreas Schwab
2014-09-12 14:12 ` Eli Zaretskii
2014-09-12 15:17 ` Eli Zaretskii
2014-09-12 15:21 ` Andreas Schwab
2014-09-12 17:15 ` Eli Zaretskii
2014-09-12 17:43 ` Andreas Schwab
2014-09-12 15:53 ` David Kastrup
2014-09-12 17:22 ` Eli Zaretskii
2014-09-12 19:28 ` David Kastrup
2014-09-12 19:59 ` Eli Zaretskii
2014-09-12 13:57 ` David Kastrup
2014-09-12 14:26 ` Eli Zaretskii
2014-09-12 11:38 ` Eric S. Raymond
2014-09-12 13:14 ` Eli Zaretskii
2014-09-12 16:27 ` Eric S. Raymond
2014-09-12 11:46 ` Harald Hanche-Olsen
2014-09-12 13:56 ` Paul Eggert
2014-09-12 15:08 ` Barry Warsaw
2014-09-12 16:16 ` Eric S. Raymond
2014-09-12 6:47 ` Thien-Thi Nguyen
2014-09-12 7:25 ` David Kastrup
2014-09-12 9:34 ` Thien-Thi Nguyen
2014-09-12 8:18 ` Eli Zaretskii
2014-09-12 8:34 ` Eric S. Raymond
2014-09-12 8:40 ` Eric S. Raymond
2014-09-12 11:47 ` Andreas Schwab
2014-09-12 11:57 ` Eric S. Raymond
2014-09-12 12:17 ` David Kastrup
2014-09-12 13:51 ` Andreas Schwab
2014-09-12 15:54 ` Eric S. Raymond
2014-09-12 16:04 ` David Kastrup
2014-09-12 16:18 ` Andreas Schwab
2014-09-12 16:28 ` Eric S. Raymond
2014-09-12 16:43 ` David Kastrup
2014-09-12 20:19 ` resolving ambiguity in action stamps (was: Everyone, please stop making my life more difficult) Joshua Judson Rosen
2014-09-12 20:41 ` Eric S. Raymond
2014-09-12 21:44 ` resolving ambiguity in action stamps Joshua Judson Rosen
2014-09-13 3:45 ` resolving ambiguity in action stamps (was: Everyone, please stop making my life more difficult) Stephen J. Turnbull
2014-09-13 5:35 ` Eric S. Raymond
2014-09-13 6:57 ` Stephen J. Turnbull
2014-09-13 7:26 ` resolving ambiguity in action stamps Harald Hanche-Olsen
2014-09-13 10:50 ` Eric S. Raymond
2014-09-13 12:43 ` Yuri Khan [this message]
2014-09-14 7:34 ` Stephen J. Turnbull
2014-09-14 10:55 ` Eric S. Raymond
2014-09-14 11:03 ` David Kastrup
2014-09-14 13:30 ` Stephen J. Turnbull
2014-09-14 14:06 ` David Kastrup
2014-09-14 15:51 ` Stephen J. Turnbull
2014-09-14 14:21 ` Eric S. Raymond
2014-09-14 15:45 ` Stephen J. Turnbull
2014-09-14 15:59 ` David Kastrup
2014-09-14 17:12 ` Eric S. Raymond
2014-09-15 0:09 ` Stephen J. Turnbull
2014-09-13 8:51 ` Andreas Schwab
2014-09-12 14:12 ` Everyone, please stop making my life more difficult Sam Steingold
2014-09-12 14:36 ` David Kastrup
2014-09-12 14:44 ` Yuri Khan
2014-09-12 15:24 ` Sam Steingold
2014-09-12 15:59 ` David Kastrup
2014-09-12 16:12 ` Eric S. Raymond
2014-09-12 17:06 ` Stefan Monnier
2014-09-12 20:35 ` Thien-Thi Nguyen
2014-09-12 15:21 ` Sam Steingold
2014-09-12 15:34 ` Harald Hanche-Olsen
2014-09-12 15:51 ` David Kastrup
2014-09-12 17:44 ` Stephen J. Turnbull
2014-09-12 17:58 ` David Caldwell
2014-09-12 19:19 ` Stephen J. Turnbull
2014-09-12 18:01 ` Harald Hanche-Olsen
2014-09-12 19:36 ` Joshua Judson Rosen
2014-10-28 21:11 ` Randal L. Schwartz
2014-09-12 15:30 ` Phillip Lord
2014-09-12 15:57 ` David Kastrup
2014-09-12 17:10 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAP_d_8UZ7LMACmgrRAMbwmrw-T4QPgfN5n=B5x3OQ4GF0O4VFA@mail.gmail.com' \
--to=yuri.v.khan@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=esr@thyrsus.com \
--cc=hanche@math.ntnu.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.