Re: [PATCH v2 15/16] tag: implicitly supply --list given the -n option

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> Change the "tag" command to treat the "-n" invocation as a list-like
> option in addition to --contains, --points-at etc.
>
> Most of the work for this was done in my earlier "tag: Implicitly
> supply --list given another list-like option" commit, but I've split
> off this patch since it's more contentious. Now these will be
> synonymous:
>
>     git tag -n 100
>     git tag -n --list 100

Hmph.  I would understand if these meant the same thing:

    git tag -l -n 100
    git tag -l -n=100
    git tag -l -n100

with or without "-l".  And accepting any of the above three without "-l"
instead of rejecting is a very good change, I would think.

I however do not understand how accepting this:
    
    git tag -n --list 100

would be a good thing, as "100" an optional parameter to the "-n"
option.

> Whereas before the former would die. This doesn't technically
> introduce any more ambiguity than the aforementioned change applied to
> th other list-like options, but it does introduce the possibility for
> more confusion, since instead of the latter of these dying:
>
>     git tag -n100
>     git tag -n 100
>
> It now works entirely differently, i.e. invokes list mode with a
> filter for "100" as a pattern. I.e. it's synonymous with:
>
>     git tag -n --list 100

Ahhh, yuck.  OK, so in "git tag -n --list 100", 100 does not have
anything to do with the -n option.  It is a pattern and -n specifies
"just one line" by default.

Oh, boy, that is confusing.  While it is very logical.

Still I think it is OK as I can see why people who wanted to have
'-n' in the first place may want

    git tag -n -l <pattern>

Thanks.