Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Sep 18, 2015, 15:30 UTC
- Message-ID
- <vpqr3lviw38.fsf@anie.imag.fr>
- In-Reply-To
- <CAOLa=ZRPwoNJv9kG7GfG4ZyjHAoPa7h2PDXErZbV1_B1_ipZ7g@mail.gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
Show 15 quoted lines
> On Fri, Sep 18, 2015 at 8:49 PM, Matthieu Moy > <Matthieu.Moy@grenoble-inp.fr> wrote: >> Karthik Nayak <karthik.188@gmail.com> writes: >> >>> Not sure this is much of a problem with regards to "--[no-]merged" >>> I mean isn't the square brackets self-explanatory? >> >> Well, usually --no-foo means "cancel the effect of --foo", ie. "git >> command --foo --no-foo" is equivalent to "git command". >> >> Here, --no-merged=some-ref does not _cancel_ the effect but introduce a >> new behavior that was not the default. So it may make sense to explain >> this more clearly. > > maybe we should s/no/not ? makes not sense to me
It's too late to rename the option without a transition plan (people's finger and scripts use --no-merged already).
But that would be a good idea to introduce --not-merged as a synonym to --no-merged, and deprecate --no-merged (it can remain a deprecated alias forever if needed, but we should promote --not-merged in the docs).
-- Matthieu Moy http://www-verimag.imag.fr/~moy/