Matthieu Moy <Matthieu.Moy@xxxxxxx> writes:
> Signed-off-by: Matthieu Moy <Matthieu.Moy@xxxxxxx>
> ---
> revision.c | 74 ++++++++++++++++++++++++++++++++++---------------------
> t/t4202-log.sh | 7 +++++
> 2 files changed, 53 insertions(+), 28 deletions(-)
>
> diff --git a/revision.c b/revision.c
> index 7e82efd..359b1a1 100644
> --- a/revision.c
> +++ b/revision.c
> ...
> @@ -1295,6 +1305,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> revs->pretty_given = 1;
> get_commit_format(arg+8, revs);
> } else if (!prefixcmp(arg, "--pretty=") || !prefixcmp(arg, "--format=")) {
> + /*
> + * Detached form ("--pretty X" as opposed to "--pretty=X")
> + * not allowed, since the argument is optional.
> + */
> revs->verbose_header = 1;
> revs->pretty_given = 1;
> get_commit_format(arg+9, revs);
The patch overall looks good, and this comments illustrates the issue
rather well. When the user wants to use "--longopt val" syntax, s/he
needs to know that "--longopt" will always take a value. Arguably
majority of options that can take value will, but like "--stat X,Y" this
leaves things inconsistent. Without "--longopt value" patch there won't
be such an inconsistency, but I think this patch series is lessor of two
evils.
Don't you by the way regret the naming of the parsing function by now?
There is nothing "diff" about it anymore.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html