From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Fri, 18 Mar 2011 09:42:17 GMT
Subject: Re: [PATCH/RFD 0/2] revision.c: --merges, --no-merges and --merges-only
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:
> 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