Re: [PATCH] send-email: clarify dual-mode behavior

Bagas Sanjaya [off-list ref] writes:

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 <redacted>
---
 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.

 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.

On Fri, Sep 24, 2021 at 10:53 AM Junio C Hamano [off-list ref] wrote:

quoted

+'git send-email' [<options>] <file|directory>...
+'git send-email' [<options>] <revision range>

... this is not improving Thiago's [3/3], I suspect.

I think it does; after all, the original (which I know you proposed)
did confuse Bagas who thought it might be missing the tagging of being
optional.

The other reasons why this might be better are :
* because of the points and examples you provided, a vague [<options>]
is better than something that might imply all options taken from
format-patch make sense here, which IMHO might be difficult to
understand as logical to you as an experienced user.
* avoids "promoting" this mode, which is known to be problematic as it
could lead to patch bombs without the proper review.  it might even be
worth adding mentions to --compose or --annotate to avoid that.

Carlo