Re: BUG: "git branch --contains <commit> <name>" does nothing, silently fails

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

 



On Fri, Mar 10, 2017 at 11:43:15AM +0100, Ævar Arnfjörð Bjarmason wrote:

> Ran into this when preparing my --no-contains series, this is a long
> standing bug:
> 
>     $ ./git branch -D test; ./git branch --contains v2.8.0 test; echo
> $?; git rev-parse test
>     error: branch 'test' not found.
>     0
>     test
>     fatal: ambiguous argument 'test': unknown revision or path not in
> the working tree.

Isn't that asking to list branches starting with "test" that contain
v2.8.0? There are none to report (since you just made sure to delete
it), so the empty output is correct.

> I.e. this should return an error like "git tag" does:
> 
>     $ ./git tag -d test; ./git tag --contains v2.8.0 test; echo $?;
> git rev-parse test
>     error: tag 'test' not found.
>     fatal: --contains option is only allowed with -l.
>     128
>     test
>     fatal: ambiguous argument 'test': unknown revision or path not in
> the working tree.

The difference between "branch" and "tag" here is that "branch
--contains" implies "--list" (and the argument becomes a pattern).
Whereas "tag --contains" just detects the situation and complains.

If anything, I'd think we would consider teaching "tag" to behave more
like "branch".

-Peff



[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]