Re: [PATCH] tag: duplicate mention of --contains should mention --no-contains

> On Mon, May 15, 2017 at 4:20 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:
>> On 2017-05-15 08:23 AM, Ævar Arnfjörð Bjarmason wrote:
>>>
>>> Fix a duplicate mention of --contains in the SYNOPSIS to mention
>>> --no-contains.
>>>
>>> This fixes an error introduced in my commit ac3f5a3468 ("ref-filter:
>>> add --no-contains option to tag/branch/for-each-ref", 2017-03-24).
>>>
>>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>> ---
>>>  Documentation/git-tag.txt | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
>>> index f8a0b787f4..1eb15afa1c 100644
>>> --- a/Documentation/git-tag.txt
>>> +++ b/Documentation/git-tag.txt
>>> @@ -12,7 +12,7 @@ SYNOPSIS
>>>  'git tag' [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>]
>>>         <tagname> [<commit> | <object>]
>>>  'git tag' -d <tagname>...
>>> -'git tag' [-n[<num>]] -l [--contains <commit>] [--contains <commit>]
>>> +'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
>>
>>
>> I think
>>
>>         [--[no-]contains <commit>]
>>
>> is the usual pattern...
>>
>>>         [--points-at <object>] [--column[=<options>] | --no-column]
>>>         [--create-reflog] [--sort=<key>] [--format=<format>]
>>>         [--[no-]merged [<commit>]] [<pattern>...]
>>
>>
>> ... like with --[no-]merged, there.
>>
>>                 M.
>
> Thanks for the feedback, this was discussed earlier in the series and
> we decided on the current format I'm submitting here.
>
> Saying --[no-]merged is the convention we use for options where the
> two are mutually exclusive, as is the case with the --[no-]merged
> options:
>
>     $ git tag --merged v2.12.0 --no-merged v2.13.0
>     error: option `no-merged' is incompatible with --merged
>     [...]
>
> But in the case of --contains and --no-contains you can provide both:
>
>     $ git tag --contains v2.12.0 --no-contains v2.13.0 'v*'
>     v2.12.0
>     v2.12.1
>     v2.12.2
>     v2.12.3
>     v2.13.0-rc0
>     v2.13.0-rc1
>     v2.13.0-rc2
>
> So they don't use that convention, since it would imply that they're
> mutually exclusive, rather than both being optional.