On Fri, Mar 10, 2017 at 1:42 PM, Jeff King <peff@xxxxxxxx> wrote:
> 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".
Yes you're right, sorry about the noise, e.g. this works:
git branch --contains v2.8.0 'a*'
git branch --contains v2.8.0 --list 'a*'
Whereas with "git tag" you always need -l as you point out.