Web lists-archives.com

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




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