Re: [PATCH/RFD 0/2] revision.c: --merges, --no-merges and --merges-only
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- Mar 18, 2011, 09:42 UTC
- Message-ID
- <4D8328F9.9050100@drmicha.warpmail.net>
- In-Reply-To
- <20110318090724.GB16703@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 18.03.2011 10:07:
Show 9 quoted lines
> On Fri, Mar 18, 2011 at 08:56:51AM +0100, Michael J Gruber wrote: > >>> However, this is totally changing the meaning of an option to plumbing >>> like rev-list (among others). Is it worth the breakage? If so, what's >>> the migration plan? Did I miss a discussion somewhere? >> >> You missed only the "D" in RFD :) > > I saw it, I was just expecting you to start the "D" with some text. :)
According to my expectation, I get many more responses doing it this way :)
I'll try to be good next RFD-time, and I'll reshape my series according to n-state.
Maybe you can help me understand this one:
int parse_opt_tertiary(const struct option *opt, const char *arg, int unset)
{
int *target = opt->value;
*target = unset ? 2 : 1;
return 0;
}This is no tri-state, is it? (It's used only for the undocumented --autoupdate option to rerere.) I guess it's more like unset/yes/no, which, admittedly, counts to 3, but still.
Anyway, I won't try parse_optifying revision.c
Michael