bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib-tool --version


From: Eric Blake
Subject: Re: gnulib-tool --version
Date: Fri, 14 Mar 2008 22:37:41 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[adding the git list]

According to Bruno Haible on 3/14/2008 10:12 PM:
| Take an example: Until 3 days ago,
|   $ git log 532f
| was equivalent to
|   $ git log 532f4b4a94e7df8e730e433d4cba9e4119641691
|
| But then there was a commit 532f65ac8de5a89ea0b159fc3b76ead5a53e9fea. Since
| then,
|   $ git log 532f
| gives an error message
|   error: short SHA1 532f is ambiguous.
|   fatal: ambiguous argument '532f': unknown revision or path not in the
working tree.
|   Use '--' to separate paths from revisions

The message comes from 'git rev-parse', which is called under the hood by
most other git commands to resolve a SHA1 prefix into a commit.

|
| To exclude the problem of ambiguous commit ids, with a reasonable
probability,
| I would therefore take the first 8 hex digits, not only the first 4.

'git rev-parse', and thus 'git describe', defaults to 7 hex digits, and
will display no fewer than 4 (although it displays as many as are
necessary to have a non-ambiguous output at the time it is run).  gnulib's
git-version-gen script intentionally asks 'git describe' for the shortest
prefix, on the grounds that developers don't like to type long random
strings, rather than sticking with the default of 7.

What is really needed is a method in git where once a SHA1 prefix becomes
ambiguous, you can still easily choose to resolve the ambiguity in favor
of the oldest commit that matches the prefix.  This is on the grounds that
there are times when the user knows that the prefix was generated by 'git
describe', and was not ambiguous at the time it was abbreviated.
Unfortunately, I don't know such a command option or special syntax to
'git rev-parse' to make this resolution occur.  And what's worse, the
error message from 'git rev-parse' doesn't help - it only states that the
prefix is either missing or ambiguous.  It would be much nicer to know
that the prefix is now too short (vs. never existed), to then know to try
the option to list all the alternative candidates and/or pick the oldest.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfbUpUACgkQ84KuGfSFAYDsewCgrD9hRriDEYGWd/WlWIxLDRk6
yVYAoJMIPljUvCnqS4w38Kg2ckI9g88C
=dDhg
-----END PGP SIGNATURE-----




reply via email to

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