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. So I think this is a bad change. Maybe check-ref-format should reject 40-hexdigit refnames? [...] > --- a/t/t1512-rev-parse-disambiguation.sh > +++ b/t/t1512-rev-parse-disambiguation.sh > @@ -261,4 +261,19 @@ test_expect_success 'rev-parse --disambiguate' ' > test "$(sed -e "s/^\(.........\).*/\1/" actual | sort -u)" = 000000000 > ' > > +test_expect_success 'rev-parse 20-hex ref' ' > + REF=`git rev-parse HEAD` && > + VAL=`echo| git commit-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904` && > + git update-ref refs/heads/$REF $VAL && > + test `git rev-parse $REF` = $VAL > +' This is a good thing to test. Nit: outside of t0000, please use empty_tree=$(git mktree </dev/null) && instead of hard-coding the hash. Otherwise you are making my life hard when I write md5git. :) And more importantly, this makes the meaning of the test easier to understand by reading it. Thanks, Jonathan -- 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