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

From: Jeff King <peff@peff.net>
Date: Mar 10, 2017, 12:42 UTC
Message-ID: <20170310124247.jvrmmcz2pbv4qf3o@sigill.intra.peff.net>
In-Reply-To: <CACBZZX7OSH_dSJ+kswbv2g1Hv6JieDxHHRmqazppgih0d1+hVg@mail.gmail.com>

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

Show 10 quoted lines

> 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.

Show 10 quoted lines

> 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