Re: [PATCH/RFD 0/2] revision.c: --merges, --no-merges and --merges-only

[Jeff King <peff@peff.net>]

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. :)

> The meaning of a plumbing option can't be changed light-heartedly, of
> course. OTOH, the current design is *really bad* from the ui point of
> view. The expectation that
> 
> "cmd --no-foo --foo" is eq. to "cmd --foo"
> 
> and
> 
> "cmd --foo --no-foo" is eq. to "cmd --no-foo"

I absolutely agree it's bad.

> should be valid universally. In the long run, we might even try and
> convert revision.c to parse_options, thereby gaining --no-foo for every
> --foo.

Another nice side effect would be short-option bundling. Every once in a
while I try something like "git log -pb" and it fails (though it is very
rare to come across these days, since everything _except_ revision and
diff options uses parse_options, and those two have very few short
options).

> So, my RFD really consists of two things:
> 
> - provide a way to override --no-merges/no_merges

Having read Junio's much longer and more intelligent response (compared
to mine) to your initial mail, I think the multi-state selector is the
right way to do this. And it has makes the transition easy, since the
new option appears, then eventually the old options can go away or be
renamed.

> In 2.0 or so, we could change "--merges" to be an alias for
> "--merges-also" rather than "--merges-only" (but don't have to).

Right. My big question reading your patches was when this switch was
supposed to happen (in your series, --merges goes away in the first
patch :) ).

-Peff