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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

> Yeah I see now that this is rather badly explained. I'll fix this up
> for v3. All of this worked already:
>
>     $ ./git tag 100
>     $ ./git tag -n -l 100
>     100             tag: add tests for --with and --without
>     $ ./git tag -l -n 100
>     100             tag: add tests for --with and --without
>
> So actually thinking about it again it doesn't add any more ambiguity
> than we had before. The change is just strictly getting rid of the
> need for -l for consistency with --contains, --points-at etc.
>
> I see now that the whole thing that led me down this golden path was
> that I was removing the failing "git tag -n 100" test,...

Wait a minute.  I do not think I would agree with the behaviour of
the last one, if "tag -l -n 100" is taking 100 as a pattern, not a
numerical argument to "-n".  That sounds utterly broken.

Is it because we use it OPT_OPTARG, which requires it to be spelled
as "-n100" or "-n=100" or somesuch?

In any case, it is not a new confusion this series introduces, so
let's include it in the series, but I'd prefer to see it kept as a
separate patch, at least for now.  Maybe somebody else have an idea
to resolve this apparent confusion in a cleaner way.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]