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
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.
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