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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 23, 2008, 23:51 UTC
Message-ID: <7v8wwvg15z.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080623233146.GP13395@artemis.madism.org>

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.