Re: [PATCH] send-email: clarify dual-mode behavior
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 24, 2021, 17:53 UTC
- Message-ID
- <xmqq35ptx3l5.fsf@gitster.g>
- In-Reply-To
- <20210924121352.42138-1-bagasdotme@gmail.com>
Bagas Sanjaya <bagasdotme@gmail.com> writes:
Show 10 quoted lines
> git send-email can be operated in two modes: one that sends > already-prepared patches and one that generates patches from > revision range on-the-fly for sending. Clarify it in the documentation > and usage help. > > Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> > --- > This patch is based on [PATCH v5 2/3] send-email: programmatically > generate bash completions [1]. PATCH v5 3/3 can be replaced with > this patch, or be integrated as stand-alone patch.
Hmph. I appreciate your enthusiasm, but I am not sure about this change.
Show 6 quoted lines
> > Questions: > > 1. Do all supported revision range syntaxes from git rev-list also be > accepted by git send-email? I only test `A..B` and `B ^A` syntaxes > and assumed that all are supported.
We do not have to ask that question if we said "format-patch options" instead of ""revision range".
> 2. Does git send-email also accepts options understood by git > rev-list?
This becomes an irrelevant question if we used "format-patch options" instead of "revision range". Does git format-patch accept options understood by git rev-list? Very likely, given that it shares the underlying option parser. Do all options understood by git rev-list make sense in that context? Absolutely not. What does "git format-patch --left-right --boundary" even mean, for example?
But "git format-patch -U5 master" would make sense (show the commits not yet in 'master' in patch form, but using 5-line context instead of the usual 3). So it is not "revision range", but more like "what format-patch takes".
So from that point of view ...
> +'git send-email' [<options>] <file|directory>... > +'git send-email' [<options>] <revision range>
... this is not improving Thiago's [3/3], I suspect.
Thanks.