Re: resolving ambiguity in action stamps

["Stephen J. Turnbull" <stephen@xemacs.org>]

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?

Speaking of databases: since AFAIK you're basically done creating git
blobs and trees (ie, except for new commits to the public repo), I
assume you are using a pre-primed object db when you run your
conversion?  If not, you should get a 20% speed up or so.  You might
be able to get a lot more speed up if you could just work with bzr log
and git filter-branch.  (That's a pretty crazy idea and quite possibly
not at all worth the work even if possible.  But let me throw it out
there....)

 > > 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.

That's not what I'm talking about.  I'm talking about
2014/09/15!esr@thyrsus.com vs. 2014-09-15/esr@thyrsus.com vs.
9/15/2014!esr vs. ....  People *will* handwrite those references,
precisely because they're more or less human-readable.

 > > Existence proof comes before characterization, please.

Ie, I suppose you don't get any collisions in referenced revisions.
But we know that there could be.  Maybe "almost correct" is good
enough for you, but I think Emacs deserves better from its VCS.  Worse
is not better when best already exists.