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