Re: [PATCH/RFD 0/2] revision.c: --merges, --no-merges and --merges-only
- From
Jeff King <peff@peff.net>
- Date
- Mar 18, 2011, 08:56 UTC
- Message-ID
- <20110318085616.GA16703@sigill.intra.peff.net>
- In-Reply-To
- <7vbp18yh1f.fsf@alter.siamese.dyndns.org>
On Fri, Mar 18, 2011 at 01:22:20AM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes: > > > From the ui perspective I'm somehow not a big fan of tri-state options > > but can't give hard reasons why; maybe because they force you to use > > option arguments. > > But in this particular case, you cannot really hack it with two options > that appear independent on surface but in reality are not. Logically, it > is an enum <everything, non-merges, merges-only> and you can choose only > one of them, and it is even worse from the UI perspective to use > combination of two not-quite-independent options. > > Also I have a hidden agenda to add "because we could" --show=octopus to > the enum later perhaps only to my private edition ;-)
Yes, I read your other response to Michael and I think that makes the most sense. In the most general form it is "--show=<num_parents>", though I don't think there is really much point in values besides 0, 1, 2, or >2 (or combinations thereof, though again, probably only "this particular value" or "any" is of interest).
So what you have said so far covers that, except for "--show=roots", which I think would be a useful addition.
The over-engineer in me wants to have the general form "--grep-by-parent-count=0,1" and "--show=no-merges" as a human-friendly alias to that. But I can't think of a good reason to have the general form, except for the sake of generalizing.
-Peff