Re: [PATCH 4/5 v4] log: parse detached options like git log --grep foo
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 2, 2010, 17:03 UTC
- Message-ID
- <7vvd7tlzfu.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1280478669-22973-4-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Show 22 quoted lines
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> 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.