Re: resolving ambiguity in action stamps

[Stephen J. Turnbull]

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.  "Think hard" (your words!) about the workflow:

    Find a bug and make it work
    Then just "git blame" will find the jerk!

More seriously, it seems to me that in many cases the bug will be
localized to a particular commit using bisect.  In others, the *place*
of the bug is known, and git blame will indeed give a pretty good idea
of the commit whether you know *when* it was introduced or not.  (Of
course the bug patch may have been shadowed by a later change in the
same place, but it's not clear to me how else one would get a revision
id for an "old" bug found by place.)  If the bug is recent enough --
ie, the only commit in the pull that broke your Emacs -- it's trivial
to get the commit.  If it's a bit older, I suspect grepping the log
for file and function is more likely to catch the culprit than looking
for random authors and dates you think are incompetent and unlucky
respectively (or is it the other way around?)

So isn't it the reverse: an April Fool's joke is the only time
date!author is likely to find the commit faster?  (Of course if you
*have* the date as in the refs you advocate, git log --since/--until
will narrow it down.  But we're talking about how you figure out which
commit needs a ref to put in the log at this point.)

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

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

A 40-hexit SHA1 is unlikely to be written in any variant, except for
case.  (Well, I suppose we have a few 133t hack0rz around, and
swapping 3s and Es would play havoc....)

The "magic cookie" mapping should be a by-product of the conversion
process (did I hear somebody say his git commits should be 1-1 with
bzr commits?), and then "filter-branch --commit-filter" is your
friend, if you have a database with the mapping lying around
somewhere.

 > Thus, it seems best to me to just land on a VCS-independent and
 > human-readable version-stamp format and stay there, treating
 > VCS-specific commit-refs as a practice flaw to be avoided.

Existence proof comes before characterization, please.