Re: Bug in "git rev-parse --verify"

On 03/28/2013 05:52 PM, Junio C Hamano wrote:

Yes, if unwrapping tags is OK then this would work.

In non-trivial scripts, it makes sense to convert user input into a known and verified quantity (SHA1) once, while processing external inputs, and not have to think about it afterwards. Verifying and converting to pure-SHA1s as soon as possible has several advantages:

1. An SHA1 is a canonical representation of the argument, useful for
example as the key in a hash map for for looking for the presence of a
commit in a rev-list output.

2. An SHA1 is persistent.  For example, I use them when caching
benchmark results across versions.  Moreover, they are safe for use in
filenames.  The persistence also makes scripts more robust against
simultaneous changes to the repo by other processes, whereas if I use a
string like "branch^" multiple times, there is no guarantee that it
always refers to the same commit.

3. Verifying arguments at one spot centralizes error-checking at the
start of a script and eliminates one reason for random git commands to
fail later (when error recovery is perhaps more difficult).

4. Converting once avoids the overhead of repeated conversion from a
free-form committish into an object name if the argument needs to be
passed to multiple git commands (though presumably the overhead is
insignificant in most cases).

Undoubtedly in many cases this practice of early-verification-and-conversion is unnecessary, or the same benefit could be had from either verifying or converting without doing both. But verifying-and-converting is easy, cheap, and means not having to decide on a case-by-case basis whether it could have been avoided.

Michael