Re: [PATCH] Make builtin-tag.c use parse_options.

From: Carlos Rica <jasampler@gmail.com>
Date: Nov 12, 2007, 13:09 UTC
Message-ID: <1b46aba20711120509l104792ebo4ea9a51c710510f3@mail.gmail.com>
In-Reply-To: <7vabpmpr9y.fsf@gitster.siamese.dyndns.org>

2007/11/10, Junio C Hamano <gitster@pobox.com>:

Show 12 quoted lines

> Carlos Rica <jasampler@gmail.com> writes:
>
> > Also, this removes those tests ensuring that repeated
> > -m options don't allocate memory more than once, because now
> > this is done after parsing options, using the last one
> > when more are given. The same for -F.
>
> The reason for this change is...?  Is this because it is
> cumbersome to detect and refuse multiple -m options using the
> parseopt API?  If so, the API may be what needs to be fixed.
> Taking the last one and discarding earlier ones feels to me an
> arbitrary choice.

You can do many things with repeated options. Here in git-tag we considered two different ways to manage them: Concatenating values for the option and/or refusing more than one. I found that current option-parser can do both from the client using callbacks, as Pierre shows me, so I think it is the right way to do it.

Pierre, by default, I think that the parser should print an error when more than one option of the same type is given, in order to report it to the command-line user, but make this behaviour optional for the programmer. Specifically, I thought in this last option:

enum parse_opt_option_flags {
	PARSE_OPT_OPTARG  = 1,
	PARSE_OPT_NOARG   = 2,
	PARSE_OPT_ALLOWREP = 4
};

Show 15 quoted lines

> While I freely admit that I do not particularly find the "One -m
> introduces one new line, concatenated to form the final
> paragraph" handling of multiple -m options done by git-commit
> nice nor useful, I suspect that it would make more sense to make
> git-tag and git-commit handle multiple -m option consistently,
> if you are going to change the existing semantics.  Since some
> people really seem to like multiple -m handling of git-commit,
> the avenue of the least resistance for better consistency would
> be to accept and concatenate (with LF in between) multiple -m
> options.
>
> With multiple -F, I think erroring out would be the sensible
> thing to do, but some people might prefer concatenation.  I do
> not care either way as long as commit and tag behave
> consistently.

Then, Kristian, what are you willing to do in such case? It seems easier for me to concatenate of -m and -F options, even when both types are given. I don't know why "people" want multiple -m options, but I think that mixing -m and -F options could be interesting for them too. If someone know if this have been discussed and decided already, please give me the link.