git send-email -v

git send-email -v

[Borislav Petkov]

Hi,

when I do

$ git send-email -v --dry-run --to=me  -1
/tmp/UdA2hemFfD/v-dry-run-0001-x86-microcode-Include-vendor-headers-into-.patch
(body) Adding cc: Borislav Petkov (AMD) <bp@alien8.de> from line 'Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>'

From: Borislav Petkov <bp@alien8.de>
To: Borislav Petkov <bp@alien8.de>
Subject: [PATCH v--dry-run] x86/microcode: Include vendor headers into microcode.h
Date: Wed,  9 Aug 2023 18:34:39 +0200
Message-ID: <20230809163439.26391-1-bp@alien8.de>
X-Mailer: git-send-email 2.42.0.rc0.25.ga82fb66fed25
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):
---

The -v and --dry-run are glued together and stuck as text after "[PATCH"
in the subject.

Without -v, it works as expected, see below.

Shouldn't the option parsing error out with "-v is unrecognized option"
or so?

The git version is the latest from the repo: 2.42.0.rc0.25.ga82fb66fed25

Thx.

---
$ git send-email --dry-run --to=me  -1
/tmp/kl2hW__Izm/0001-x86-microcode-Include-vendor-headers-into-microcode..patch
(body) Adding cc: Borislav Petkov (AMD) <bp@alien8.de> from line 'Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>'
Dry-OK. Log says:
Sendmail: /usr/bin/sendmail -i bp@alien8.de
From: Borislav Petkov <bp@alien8.de>
To: Borislav Petkov <bp@alien8.de>
Subject: [PATCH] x86/microcode: Include vendor headers into microcode.h
Date: Wed,  9 Aug 2023 18:35:18 +0200
Message-ID: <20230809163518.26423-1-bp@alien8.de>
X-Mailer: git-send-email 2.42.0.rc0.25.ga82fb66fed25
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Result: OK

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: git send-email -v

[Jacob Keller]

On Wed, Aug 9, 2023 at 10:29 AM Borislav Petkov <bp@alien8.de> wrote:
>
> Hi,
>
> when I do
>
> $ git send-email -v --dry-run --to=me  -1
> /tmp/UdA2hemFfD/v-dry-run-0001-x86-microcode-Include-vendor-headers-into-.patch
> (body) Adding cc: Borislav Petkov (AMD) <bp@alien8.de> from line 'Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>'
>
> From: Borislav Petkov <bp@alien8.de>
> To: Borislav Petkov <bp@alien8.de>
> Subject: [PATCH v--dry-run] x86/microcode: Include vendor headers into microcode.h
> Date: Wed,  9 Aug 2023 18:34:39 +0200
> Message-ID: <20230809163439.26391-1-bp@alien8.de>
> X-Mailer: git-send-email 2.42.0.rc0.25.ga82fb66fed25
> MIME-Version: 1.0
> Content-Transfer-Encoding: 8bit
>
> Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):
> ---
>
> The -v and --dry-run are glued together and stuck as text after "[PATCH"
> in the subject.
>
> Without -v, it works as expected, see below.
>
> Shouldn't the option parsing error out with "-v is unrecognized option"
> or so?

-v is a valid option to git format-patch:

      -v <n>, --reroll-count=<n>
           Mark the series as the <n>-th iteration of the topic. The
output filenames have v<n> prepended to them, and the subject prefix
("PATCH" by
           default, but configurable via the --subject-prefix option)
has ` v<n>` appended to it. E.g.  --reroll-count=4 may produce
           v4-0001-add-makefile.patch file that has "Subject: [PATCH
v4 1/20] Add makefile" in it.  <n> does not have to be an integer
(e.g.
           "--reroll-count=4.4", or "--reroll-count=4rev2" are
allowed), but the downside of using such a reroll-count is that the
range-diff/interdiff with
           the previous version does not state exactly which version
the new interation is compared against.

it takes a required argument, and inserts "v<argument>" into the
[PATCH] block to describe the version.

Typically the argument should be a number, but you happened to provide
it "--dry-run". Presumably assuming that the -v means "verbose" as it
might in most other applications.

In short: this is working as intended, but it is somewhat confusing
that it doesn't validate the argument at all. It is intentional to
allow non-numeric strings, but maybe we ought to validate that it
doesn't start with -- to avoid such confusion here.

In short: -v doesn't mean verbose, it is a valid option, and while its
a bit non-intuitive in this case, I think it is working as designed
now.

Thanks,
Jake

Re: git send-email -v

[Borislav Petkov]

On Wed, Aug 09, 2023 at 10:42:54AM -0700, Jacob Keller wrote:
> -v is a valid option to git format-patch:
> 
>       -v <n>, --reroll-count=<n>
>            Mark the series as the <n>-th iteration of the topic. The
> output filenames have v<n> prepended to them, and the subject prefix
> ("PATCH" by
>            default, but configurable via the --subject-prefix option)
> has ` v<n>` appended to it. E.g.  --reroll-count=4 may produce
>            v4-0001-add-makefile.patch file that has "Subject: [PATCH
> v4 1/20] Add makefile" in it.  <n> does not have to be an integer
> (e.g.
>            "--reroll-count=4.4", or "--reroll-count=4rev2" are
> allowed), but the downside of using such a reroll-count is that the
> range-diff/interdiff with
>            the previous version does not state exactly which version
> the new interation is compared against.
> 
> it takes a required argument, and inserts "v<argument>" into the
> [PATCH] block to describe the version.

Aaaah.

> Typically the argument should be a number, but you happened to provide
> it "--dry-run". Presumably assuming that the -v means "verbose" as it
> might in most other applications.

Yap.

> In short: this is working as intended, but it is somewhat confusing
> that it doesn't validate the argument at all. It is intentional to
> allow non-numeric strings, but maybe we ought to validate that it
> doesn't start with -- to avoid such confusion here.

Yes, the non-intuitiveness is kinda confusing.

> In short: -v doesn't mean verbose, it is a valid option, and while its
> a bit non-intuitive in this case, I think it is working as designed
> now.

Thanks for explaining!

:-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: git send-email -v

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

> In short: this is working as intended, but it is somewhat confusing
> that it doesn't validate the argument at all. It is intentional to
> allow non-numeric strings, but maybe we ought to validate that it
> doesn't start with -- to avoid such confusion here.

I think both of your points are quite reasonable here.