Re: rev-list and "ambiguous" IDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 15.11.2019 um 04:49 schrieb Jeff King:
> On Fri, Nov 15, 2019 at 01:12:47AM +0100, Thomas Braun wrote:
> 
>>> That would probably help in a lot of cases, but the argument
>>> against it is that when it goes wrong, it may be quite confusing (so
>>> we're better off with the current message, which punts back to the
>>> user).
>>
>> Just out of curiosity: Is there a use case for inspecting non-commit
>> objects with git log?
> 
> Not that I can think of. You can't even say "--objects" there.
> 
> And indeed, "git log" already prefers commits for disambiguation, since
> d5f6b1d756 (revision.c: the "log" family, except for "show", takes
> committish, 2012-07-02).
> 
> But...
> 
>> If I do (in the git repo)
>>
>> $ git log 1231
>>
>> I get
>>
>> error: short SHA1 1231 is ambiguous
>> hint: The candidates are:
>> hint:   123139fc89 tree
>> hint:   12316a1673 tree
>> hint:   123144fe8a blob
>> fatal: ambiguous argument '1231': unknown revision or path not in the
>> working tree.
>> Use '--' to separate paths from revisions, like this:
>> 'git <command> [<revision>...] -- [<file>...]'
>>
>> with
>> $ git --version
>> git version 2.24.0.windows.2
>>
>> and all of these candidates are no commits.
> 
> ...remember that the disambiguation code is just about preferring one
> object to the other. If the rule in effect doesn't have a preference,
> it's still ambiguous. On my system, "1231" actually _does_ have a
> commit:
> 
>   $ git show 1231
>   error: short SHA1 1231 is ambiguous
>   hint: The candidates are:
>   hint:   12319e3bf2 commit 2017-03-25 - Merge 'git-gui-add-2nd-line' into HEAD
>   hint:   123139fc89 tree
>   hint:   12315b58b8 tree
>   hint:   12316a1673 tree
>   hint:   12317ab2d9 tree
>   hint:   123193f802 tree
>   hint:   123144fe8a blob
>   fatal: ambiguous argument '1231': unknown revision or path not in the working tree.
>   Use '--' to separate paths from revisions, like this:
>   'git <command> [<revision>...] -- [<file>...]'
> 
> That's ambiguous because git-show can handle trees and blobs, too. But
> if I feed that sha1 to git-log:
> 
>   $ git log --oneline -1 1231
>   12319e3bf2 Merge 'git-gui-add-2nd-line' into HEAD
> 
> it's perfectly fine, because git-log knows to disambiguate the commit.
> But if I choose another prefix that has no commits at all, it's
> ambiguous under either, because the "committish" rule has no way to
> decide:
> 
>   $ git show abcd2
>   error: short SHA1 abcd2 is ambiguous
>   hint: The candidates are:
>   hint:   abcd22f55e tree
>   hint:   abcd238df0 tree
>   hint:   abcd2b1cc8 blob
>   
>   $ git log abcd2
>   error: short SHA1 abcd2 is ambiguous
>   hint: The candidates are:
>   hint:   abcd22f55e tree
>   hint:   abcd238df0 tree
>   hint:   abcd2b1cc8 blob

I would have expected that git log did just tell me that it could not
find something commitish, instead it told me that there are multiple
candidates, all of them being no commit.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux