Re: Policy on referencing/abbreviating git commit-IDs, going forward?

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

Andreas Schwab <schwab@linux-m68k.org> writes:
>
> Joshua Judson Rosen <rozzin@geekspace.com> writes:
>
> > abbreviation ambiguous, how will you trace out the now-ambiguously-
> > abbreviated commit? e.g.: up through July 29 2012, "7a62fbf"
> > unambiguously identified a commit from October 24 2007; on July 30 2012,
> > "7a62fbf" stopped being unambiguous.
>
> If you know it was previsouly unambiguous you know that it refers to the
> older one.

I don't think one necessarily _does_ know that in any meaningful way,
when the situation crops up analogously to how it just did; I'm just
thinking, it may be worth putting a "do not use abbreviated sha1 refs in
your commit comments" or similar policy statement somewhere prominent in
the wiki and other docs, if it's not already there.

When you find an abbreviated ref in a revision that got merged in
from another branch/repository (which is what just happened), you only
know that it was previously unambiguous _in the author's own local
repository_ where the text using the abbreviation was written, not
that it was previously unambiguous in the mainline repository, and
certainly not that it was previously unambiguous in the mainline
repository's trunk branch (or in any other particular branch).

Not everyone pulls/pushes all branches when they sync with the mainline
repository, so it's entirely possible that two developers working on
separate branches to not have each others ambiguously-abbreviated
revisions in their own repositories (even when one of those branches is
the trunk). I'm not sure what the probability is over however long git
will be in use; the probability surely increases if more developers
more-abbreviated refs, though.

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