Re: [PATCH 4/5 v4] log: parse detached options like git log --grep foo
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:49:14
Matthieu Moy [off-list ref] writes:
quoted hunk
Signed-off-by: Matthieu Moy <redacted> --- 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.