Re: resolving ambiguity in action stamps

["Eric S. Raymond" <esr@thyrsus.com>]

Stephen J. Turnbull <stephen@xemacs.org>:
> 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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>