On Thu, May 2, 2013 at 1:43 AM, Jonathan Nieder <jrnie...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html