From: Duy Nguyen <pclouds@gmail.com>
Date: Thu, 02 May 2013 10:09:29 GMT
Subject: Re: [PATCH/RFC] get_sha1: prefer 40-hex ref name over 40-hex SHA-1
Message-ID: <CACsJy8AOEEAJ6jtcaAWmrfCbejq8SLcEsUNSsrOEJ6he+5CByA@mail.gmail.com>
In-Reply-To: <20130501184327.GM24467@google.com>

On Thu, May 2, 2013 at 1:43 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Nguyễn Thái Ngọc Duy wrote:
>
>>                                              "git rev-parse 1234" will
>> resolve refs/heads/1234 if exists even if there is an unambiguous
>> SHA-1 starting with 1234. However if it's full SHA-1, the SHA-1 takes
>> precedence and refs with the same name are ignored.
>
> That's an important feature for safety.  When a script has created an
> object or learned about it some other way, as long as it doesn't
> abbreviate its name it can be sure that git commands will not
> misunderstand it.

Then what about abbrev sha-1? You pick up an abbrev sha-1 from "git
log --oneline", do "git show <abbrev>". If you happen to have
refs/heads/<abbrev> then what you see is not what you intend to see.
Warn about ambiguity and move on? Banning all sha1-alike refs seems
unreasonable (or not? I don't know).

> So I think this is a bad change.  Maybe check-ref-format should
> reject 40-hexdigit refnames?

I tried that first. The test suite screamed. Will do that again and
figure out soon.
--
Duy