Web lists-archives.com

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




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.