Hello Eric,
On 2024-04-19 02:15, Eric Sunshine wrote:
On Thu, Apr 18, 2024 at 6:34 PM Junio C Hamano <gitster@xxxxxxxxx>
wrote:
Dragan Simic <dsimic@xxxxxxxxxxx> writes:
> How about introducing "--label=<string>" as the new option,...
I still think --rfc=WIP is a lot more natural and easier to
understand, and it is just the matter of how you introduce it.
I'll show you how in a separate patch later.
The problem I see with an overly generic word like "label" is that
it would mislead readers to say "--label=important" and expect it to
appear on an extra e-mail header, not as a part of "Subject:".
But we can do this to get the ball rolling, without bikeshedding
what option name to use. Until we find a good name, users can
use --rfc=WIP and when we do find a good name, it can be added
as a synonym, possibly deprecating --rfc, and if we never agree
on a good name, that is fine as well.
I remain skeptical that adding such an option is necessary, even
though I made a similar suggestion earlier in this discussion as an
alternative to `--resend`. I'm especially skeptical since the existing
`--subject-prefix` covers this use-case already (i.e.
`--subject-prefix="RESEND PATCH"`). It's dead simple to use and
doesn't require any magical incantations with corresponding complex
implementation such as the proposed `--label=RESEND$` which renders as
"[PATCH RESEND]" instead of "[RESEND PATCH]"; `--subject-prefix`
already handles this without any need for magic.
I do understand and am sympathetic to the desire to reduce the typing
load (hence, the original `--resend` proposal), but I have difficulty
believing that `git format-patch` is so commonly used throughout the
day that the time saved by typing `--resend` over
`--subject-prefix="RESEND PATCH"` warrants the extra implementation,
documentation, and testing baggage. Likewise, I don't see the value in
`--label=WIP` (or `--rfc=WIP` or whatever) over the existing more
general `--subject-prefix`.
An additional reason, IMHO, for having "--rfc", "--rfc=<string>"
or "--resend" is to reuse what's already configured through the
"format.subjectPrefix" configuration option. In the sense of not
redefining what's already configured in ~/.gitconfig (in this case,
"PATCH" or "PATCH lib", for example), by specifying an additional
command-line option.
If some user configures different values for "format.subjectPrefix"
in different local repositories, such as when working on different
subsystems, it becomes rather easy to get lost in all those prefixes,
if the user needs to remember and type them entirely while using
"--subject-prefix=<string>" to add more "labels" to a prefix.
I hope it makes sense the way I wrote it above.
If reducing the typing load is the primary concern, then a very simple
middle-ground would be to give `--subject-prefix` a short alias (i.e.
`-S`). It's true that `-S "RESEND PATCH"` doesn't reduce the typing
load as much as `--resend` does over `--subject-prefix="RESEND
PATCH"`, but it seems a reasonable alternative which doesn't
significantly increase implementation, documentation, and testing
costs.
I'd support the addition of a short alias for the already existing
"--subject-prefix" option.
