Ævar Arnfjörð Bjarmason <[email protected]> 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.
