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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html