On Thu, May 2, 2013 at 1:43 AM, Jonathan Nieder 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 t
Nguyễn Thái Ngọc Duy writes:
> +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
> +'
> +
> +test
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.
Th
On Tue, Apr 30, 2013 at 11:01 PM, Nguyễn Thái Ngọc Duy
wrote:
> The current behavior is inconsistent when passing SHA-1 to get_sha1.
> If it's a short sha-1, refs take precedence. "git rev-parse 1234" will
> resolve refs/heads/1234 if exists even if there is an unambiguous
> SHA-1 starting with 12
The current behavior is inconsistent when passing SHA-1 to get_sha1.
If it's a short sha-1, refs take precedence. "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 wit
5 matches
Mail list logo