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