All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Kyle Meyer <kyle@kyleam.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] send-email: disable option auto-abbreviation
Date: Fri, 25 Nov 2022 16:11:06 +0900	[thread overview]
Message-ID: <xmqqv8n3cxv9.fsf@gitster.g> (raw)
In-Reply-To: 20221124020056.242185-1-kyle@kyleam.com

Kyle Meyer <kyle@kyleam.com> writes:

> send-email supports specifying format-patch options.  However, some
> valid format-patch short options trigger an error because Getopt's
> default auto-abbreviation is enabled.  For example, with
>
>   git send-email -v 3 @{u}
>
> the -v is consumed as send-email's --validate, and 3 is passed on to
> the format-patch call, leading to
>
>   fatal: ambiguous argument '3': unknown revision or path not in the
>   working tree.  [...]
>
> Disable Getopt's auto-abbreviation feature so that such options are
> properly relayed to format-patch.  With this change, there is some
> risk of breaking external scripts that rely on the abbreviation, but
> that is hopefully unlikely given that Git does not advertise support
> for auto-abbreviation and most subcommands do not support it.

I personally have no sympathy to those who drive "format-patch" from
inside "send-email".

Having said that.

Many subcommands of "git" do take uniquely abbreviated double-dashed
option names, but it is true that we do not allow --vanything to be
given as -v even when there is no other double-dashed option that
begins with 'v', so "git send-email -v" that stands for "git
send-email --validate" indeed is an odd thing.

But robbing "git send-email --val" that expands to "--validate" from
the users is going a bit too far, I am afraid.  The right solution
for allowing "-v 3" given to "format-patch" I think is to make
send-email understand it and pass that through.  The presence of
both ("validate" => \$validate) and ("v" => \$reroll_count) in the
GetOptions() argument would prevent "-v" to be taken as "--validate"
while still allowing "--val" to be used as an abbrevatiion, no?

By the way, do we advertise support for any and all options to
format-patch when the feature to drive it from send-email is used?
Some of the options (e.g. "-o <directory>") do not make any sense in
the context I would suspect.

  reply	other threads:[~2022-11-25  7:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24  2:00 [PATCH] send-email: disable option auto-abbreviation Kyle Meyer
2022-11-25  7:11 ` Junio C Hamano [this message]
2022-11-25 17:31   ` Kyle Meyer
2022-11-26 20:21     ` [PATCH v2] send-email: relay '-v N' to format-patch Kyle Meyer
2022-11-27  1:25       ` Junio C Hamano
2022-11-28 12:34         ` Ævar Arnfjörð Bjarmason
2022-11-28  9:41       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqv8n3cxv9.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kyle@kyleam.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.