Re: resolving ambiguity in action stamps

[Joshua Judson Rosen <rozzin@geekspace.com>]

"Eric S. Raymond" <esr@thyrsus.com> writes:
>
> Joshua Judson Rosen <rozzin@geekspace.com>:
> > Sorry--I mostly just wasn't paying close enough attention six months ago
> > to point out all of the angles of this issue...; though I *did* raise
> > this "ambiguity of reference by timestamp" issue at that time--and thought
> > that you'd given an ACK with a statement you were going to fix it by using
> > "#{sequence-number}" suffixes to distingiush between multiple distinct
> > items in the same "{ISO-date}!{email-address}" hashbucket:
> > 
> >     https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01117.html
> > 
> >     https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01113.html
> > 
> > (that first link is your response; the second is my message--which
> >  included an example of why the "same timestamps, different commit-
> >  objects" situation might exist in a repository)
>
> I remeber that.  I thought I was going to fix it that way too.
>
> Then I found a showstopper. Possibly it has a solution I haven't found yet.
>
> The problem is this: suppose you have such a suffix, and several nodes
> with the same date on a DAG.  What's your rule for mapping suffix 
> to individual node?

Hrm. I'd figured you were just going to assign sequence-numbers
according to the order in which you encountered the commits in the
git-fast-import stream, or reverse of the order in the git-fast-import
stream, or something like that. It wasn't obvious to me how that would
actually be usable in the _general_ case, but I guess I assumed you'd
found it to be sufficient in practice, and/or that you had something up
your sleeve that you hadn't explicitly mentioned (and wasn't really
keenly intent on pressing the issue at the time).

> I couldn't invent one.  I believe this is mathematically equivalent to 
> total-ordering the DAG. Which you can't do.

In the specific case that Andreas put forward (*commit* times in a
single series incrementing more rapidly than their timestamp-precision
could account for), I'd sort-of expect that to be workable with pretty
good usability--the since commits along a single branch (as in a rebase)
would seem to already have intrinsic sequencing with respect to each other.

What I put forward in my example was the sort of case where I was
skeptical of `*authorship* timestamp_bucket + seqno' being usable, but I
also noted the possibility of that situation not existing in the emacs
repository (if you don't actually encounter the general case, does it
matter whether your algorithm handles it?). Have you actually found that
sort of collision in the emacs DAG?

Actually, I guess the nature (and relevance) of that last question
changes if you're using *commit* timestamps rather and not *authorship*
timestamps--like, maybe you only have to worry about the "rebase"
situation that Andreas described, and _that_ can handled trivially?

-- 
"'tis an ill wind that blows no minds."