Re: [RFC] Re: Convert 'git blame' to parse_options()

[Junio C Hamano <gitster@pobox.com>]

Pierre Habouzit <madcoder@debian.org> writes:

>   Unrelated but worth to note: many parse_options users just don't care
> about argv[0] and having it kept each time would rather be a pain for
> them (they would need to call argv++, argc-- themselves).

Not necessarily.  If they were parsing by hand, they were written to deal
with the fact that argv[0] is not the program argument (iow, they start
counting from one).  And before and after calling parse_options(), they
need to change that assumption anyway, because parse_options() makes
argv[0] disappear.

See for example these:

 * 5eee6b2 (Make builtin-reset.c use parse_options., 2008-03-04)
	The caller used to start counting from 1, after the conversion it
	has to count from 0.

 * 8320199 (Rewrite builtin-fetch option parsing to use parse_options()., 2007-12-04)
 * 3968658 (Make builtin-tag.c use parse_options., 2007-11-09)
	The caller used to say (i==argc) is "no param" case, now it has to
	say "!argc" is the equivalent condition.

I am not saying that forcing these callers to change their loop invariants
in order to use parse_options() was bad.  I am saying that your "would
rather be a pain for them" is a bogus argument --- they needed to pay that
price when converting to parse_options() that munges argv[0] anyway.

But this argv[0] munging exactly is why parse_options() hurts users who
want to cascade option parsing.

Didn't one of the recent series have an option to tell parse_options() to
start parsing from argv[0] (persumably because it got an argument array
from somebody who munges it to drop argv[0])?  I think it was merge-in-C
from Miklos, but the approach feels very much backwards.  The caller
should be (at least) able to choose to say KEEP_ARGV0 like one of your
patch does.