{"thread":{"id":"60092","subject":"git send-email -v","startedAt":"2023-08-09T17:05:47Z","lastAt":"2023-08-09T19:11:40Z","messageCount":4,"participants":["Borislav Petkov","Jacob Keller","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"480367","messageId":"20230809170028.GKZNPGLM93GYB+7Ej9@fat_crate.local","threadId":"60092","inReplyTo":null,"subject":"git send-email -v","fromName":"Borislav Petkov","fromEmail":"bp@alien8.de","sentAt":"2023-08-09T17:00:28Z","receivedAt":"2023-08-09T17:05:47Z","isPatch":false,"sender":{"key":"bp@alien8.de","avatar":null},"body":"Hi,\n\nwhen I do\n\n$ git send-email -v --dry-run --to=me  -1\n/tmp/UdA2hemFfD/v-dry-run-0001-x86-microcode-Include-vendor-headers-into-.patch\n(body) Adding cc: Borislav Petkov (AMD) <bp@alien8.de> from line 'Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>'\n\nFrom: Borislav Petkov <bp@alien8.de>\nTo: Borislav Petkov <bp@alien8.de>\nSubject: [PATCH v--dry-run] x86/microcode: Include vendor headers into microcode.h\nDate: Wed,  9 Aug 2023 18:34:39 +0200\nMessage-ID: <20230809163439.26391-1-bp@alien8.de>\nX-Mailer: git-send-email 2.42.0.rc0.25.ga82fb66fed25\nMIME-Version: 1.0\nContent-Transfer-Encoding: 8bit\n\nSend this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):\n---\n\nThe -v and --dry-run are glued together and stuck as text after \"[PATCH\"\nin the subject.\n\nWithout -v, it works as expected, see below.\n\nShouldn't the option parsing error out with \"-v is unrecognized option\"\nor so?\n\nThe git version is the latest from the repo: 2.42.0.rc0.25.ga82fb66fed25\n\nThx.\n\n---\n$ git send-email --dry-run --to=me  -1\n/tmp/kl2hW__Izm/0001-x86-microcode-Include-vendor-headers-into-microcode..patch\n(body) Adding cc: Borislav Petkov (AMD) <bp@alien8.de> from line 'Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>'\nDry-OK. Log says:\nSendmail: /usr/bin/sendmail -i bp@alien8.de\nFrom: Borislav Petkov <bp@alien8.de>\nTo: Borislav Petkov <bp@alien8.de>\nSubject: [PATCH] x86/microcode: Include vendor headers into microcode.h\nDate: Wed,  9 Aug 2023 18:35:18 +0200\nMessage-ID: <20230809163518.26423-1-bp@alien8.de>\nX-Mailer: git-send-email 2.42.0.rc0.25.ga82fb66fed25\nMIME-Version: 1.0\nContent-Transfer-Encoding: 8bit\n\nResult: OK\n\n-- \nRegards/Gruss,\n    Boris.\n\nhttps://people.kernel.org/tglx/notes-about-netiquette\n"},{"id":"480383","messageId":"CA+P7+xrGBNO-JNfHvbVUV9AgY_Q8PgYSr5EVycGzC5+ZB7Cv3A@mail.gmail.com","threadId":"60092","inReplyTo":"20230809170028.GKZNPGLM93GYB+7Ej9@fat_crate.local","subject":"Re: git send-email -v","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2023-08-09T17:42:54Z","receivedAt":"2023-08-09T17:43:10Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Aug 9, 2023 at 10:29 AM Borislav Petkov <bp@alien8.de> wrote:\n>\n> Hi,\n>\n> when I do\n>\n> $ git send-email -v --dry-run --to=me  -1\n> /tmp/UdA2hemFfD/v-dry-run-0001-x86-microcode-Include-vendor-headers-into-.patch\n> (body) Adding cc: Borislav Petkov (AMD) <bp@alien8.de> from line 'Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>'\n>\n> From: Borislav Petkov <bp@alien8.de>\n> To: Borislav Petkov <bp@alien8.de>\n> Subject: [PATCH v--dry-run] x86/microcode: Include vendor headers into microcode.h\n> Date: Wed,  9 Aug 2023 18:34:39 +0200\n> Message-ID: <20230809163439.26391-1-bp@alien8.de>\n> X-Mailer: git-send-email 2.42.0.rc0.25.ga82fb66fed25\n> MIME-Version: 1.0\n> Content-Transfer-Encoding: 8bit\n>\n> Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):\n> ---\n>\n> The -v and --dry-run are glued together and stuck as text after \"[PATCH\"\n> in the subject.\n>\n> Without -v, it works as expected, see below.\n>\n> Shouldn't the option parsing error out with \"-v is unrecognized option\"\n> or so?\n\n-v is a valid option to git format-patch:\n\n      -v <n>, --reroll-count=<n>\n           Mark the series as the <n>-th iteration of the topic. The\noutput filenames have v<n> prepended to them, and the subject prefix\n(\"PATCH\" by\n           default, but configurable via the --subject-prefix option)\nhas ` v<n>` appended to it. E.g.  --reroll-count=4 may produce\n           v4-0001-add-makefile.patch file that has \"Subject: [PATCH\nv4 1/20] Add makefile\" in it.  <n> does not have to be an integer\n(e.g.\n           \"--reroll-count=4.4\", or \"--reroll-count=4rev2\" are\nallowed), but the downside of using such a reroll-count is that the\nrange-diff/interdiff with\n           the previous version does not state exactly which version\nthe new interation is compared against.\n\nit takes a required argument, and inserts \"v<argument>\" into the\n[PATCH] block to describe the version.\n\nTypically the argument should be a number, but you happened to provide\nit \"--dry-run\". Presumably assuming that the -v means \"verbose\" as it\nmight in most other applications.\n\nIn short: this is working as intended, but it is somewhat confusing\nthat it doesn't validate the argument at all. It is intentional to\nallow non-numeric strings, but maybe we ought to validate that it\ndoesn't start with -- to avoid such confusion here.\n\nIn short: -v doesn't mean verbose, it is a valid option, and while its\na bit non-intuitive in this case, I think it is working as designed\nnow.\n\nThanks,\nJake\n"},{"id":"480384","messageId":"20230809174621.GNZNPQ7VGaAbC9V+mu@fat_crate.local","threadId":"60092","inReplyTo":"CA+P7+xrGBNO-JNfHvbVUV9AgY_Q8PgYSr5EVycGzC5+ZB7Cv3A@mail.gmail.com","subject":"Re: git send-email -v","fromName":"Borislav Petkov","fromEmail":"bp@alien8.de","sentAt":"2023-08-09T17:46:21Z","receivedAt":"2023-08-09T17:46:34Z","isPatch":false,"sender":{"key":"bp@alien8.de","avatar":null},"body":"On Wed, Aug 09, 2023 at 10:42:54AM -0700, Jacob Keller wrote:\n> -v is a valid option to git format-patch:\n> \n>       -v <n>, --reroll-count=<n>\n>            Mark the series as the <n>-th iteration of the topic. The\n> output filenames have v<n> prepended to them, and the subject prefix\n> (\"PATCH\" by\n>            default, but configurable via the --subject-prefix option)\n> has ` v<n>` appended to it. E.g.  --reroll-count=4 may produce\n>            v4-0001-add-makefile.patch file that has \"Subject: [PATCH\n> v4 1/20] Add makefile\" in it.  <n> does not have to be an integer\n> (e.g.\n>            \"--reroll-count=4.4\", or \"--reroll-count=4rev2\" are\n> allowed), but the downside of using such a reroll-count is that the\n> range-diff/interdiff with\n>            the previous version does not state exactly which version\n> the new interation is compared against.\n> \n> it takes a required argument, and inserts \"v<argument>\" into the\n> [PATCH] block to describe the version.\n\nAaaah.\n\n> Typically the argument should be a number, but you happened to provide\n> it \"--dry-run\". Presumably assuming that the -v means \"verbose\" as it\n> might in most other applications.\n\nYap.\n\n> In short: this is working as intended, but it is somewhat confusing\n> that it doesn't validate the argument at all. It is intentional to\n> allow non-numeric strings, but maybe we ought to validate that it\n> doesn't start with -- to avoid such confusion here.\n\nYes, the non-intuitiveness is kinda confusing.\n\n> In short: -v doesn't mean verbose, it is a valid option, and while its\n> a bit non-intuitive in this case, I think it is working as designed\n> now.\n\nThanks for explaining!\n\n:-)\n\n-- \nRegards/Gruss,\n    Boris.\n\nhttps://people.kernel.org/tglx/notes-about-netiquette\n"},{"id":"480388","messageId":"xmqqv8dom3oc.fsf@gitster.g","threadId":"60092","inReplyTo":"CA+P7+xrGBNO-JNfHvbVUV9AgY_Q8PgYSr5EVycGzC5+ZB7Cv3A@mail.gmail.com","subject":"Re: git send-email -v","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-08-09T19:11:31Z","receivedAt":"2023-08-09T19:11:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller <jacob.keller@gmail.com> writes:\n\n> In short: this is working as intended, but it is somewhat confusing\n> that it doesn't validate the argument at all. It is intentional to\n> allow non-numeric strings, but maybe we ought to validate that it\n> doesn't start with -- to avoid such confusion here.\n\nI think both of your points are quite reasonable here.\n"}]}