Re: [PATCH 2/3] parseopt: introduce OPT_RECURSE to specify shared options

On Mon, 5 Nov 2007, Johannes Schindelin wrote:

After kicking this around a bit more on IRC, we had another idea.  Instead 
of introducing OPT_RECURSE(), do something like OPT__QUIET(), only this 
time in diff.h: ....

I think the preprocessor approach would tend to be simpler, which is an 
advantage. But whichever approach is chosen, I think one important issue 
is to make sure that options that *hide* other options are correctly 
handled in the help printout..

We have a few cases where a "recursive" option is hidden. For example, the 
option "-n" can mean different things in different contexts: in 
git-format-patch, for example, the "-n" is handled *before* calling 
setup_revisions() and allt he normal revision flags, which means that the 
format-patch -specific meaning of "-n" overrides the normal "revision" 
meaning. 

I suspect that in this kind of situation, it's actually easier to have a 
single linear array of options, because the option parser can just walk 
back and check "oh, I already saw this short option, so I should not 
output it as documentation because this version of it is hidden by the 
earlier one". 

But that's an implementation issue. The same certainly *can* be done with 
a recursive setup, just passing a linked list of what the earlier levels 
were (which is what we do in other places). And it's not like the 
recursion is going to be very deep or complex.

		Linus