git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: gnulib-tool --version

From
Eric Blake <ebb9@byu.net>
Date
Mar 15, 2008, 04:37 UTC
Message-ID
<47DB5295.9080005@byu.net>
In-Reply-To
<200803150512.53166.bruno@clisp.org>
-----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             ebb9@byu.net
-----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-----

Next: Junio C Hamano
Message 1 of 2 in “Re: gnulib-tool --version”
  1. Eric BlakeMar 15, 2008
  2. Junio C HamanoMar 15, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.