[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joshua Judson Rosen
Subject: Policy on referencing/abbreviating git commit-IDs, going forward? (was: Can anyone correct the Bazaar reference "revno:111954.1.97"?)
Date: Sun, 02 Mar 2014 15:01:50 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Andreas Schwab <address@hidden> writes:
> Eli Zaretskii <address@hidden> writes:
> > This is bzr, not git, so the diffs aren't the whole story.
> There is no difference between git and bzr wrt. to the DAG.  Only the
> names they use are different.

There is an interesting `bzr vs. git' question here, though--because of
the differences in the way revisions are named: when you run into the
analogous "I can't tell what this reference is to" problem in git, how
will you deal with it? When someone writes a abbreviated git sha1sum
into a changelog / commit message because just the first 7 or
howevermany hexits was enough to unambiguously identify the referenced
commit-object in their development environment at the time when they
were committing their change, and then a later commit/merge makes that
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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]