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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to