Re: PATCH/RFC: format-patch: Add format.subjectprefixsep to change separators

[Marc Finet <m.dreadlock@gmail.com>]

On Sun, Jan 04, 2015 at 11:55:24AM -0800, Junio C Hamano wrote:
> Marc Finet <m.dreadlock@gmail.com> writes:
> 
> > Some mailing list use "PATCH:" rather than "[PATCH]" to prefix
> > patches, so introduce a new option to configure:
> >  - 2 chars that would enclose PATCH (and counters)
> >  - 1 char that would come just after the PATCH (and counters)
> > ---
> > This mail has been sent with:
> >  git -c format.subjectprefixsep=: send-email --annotate --subject-prefix=PATCH/RFC
> 
> A few comments:
> 
>  - "Some mailing lists" may want to say "[PATCH v3 #4 of 10]" or
>    somesuch; as a customization mechanism, the approach this patch
>    takes falls way short to be useful.  "--subject=<format>" option
>    where <format> is similar the "log --format" options, e.g.
> 
>    --subject="[PATCH% v #%N of %T] %s"
> 
>    with format-patch specific set of substitutions (in the above
>    example, %v stands for patch version, %N patch number and %T
>    total number of patches in the series) may be a better way to go.
In fact the log-tree.c::log_write_email_headers() has two cases
depending on the number of patches to send. So we need either two (or
three) options or we need to implement (because AFAIK it does not exists
yet) conditionals. Both seemed to me a little bit overkill here.
 
>  - Do not add configuration variable before you add command line
>    option.  Add option first and then when option proves useful you
>    can have the corresponding variable, not the other way around.
>    Make sure that the comamnd line option overrides configuration
>    variable while adding the variable in the second step of such a
>    patch series.
Ok.

> Having said all that.
> 
> What are these mailing lists and why are they using non-standard
> convention?  Back when Git was young, we would have added more knobs
> to adjust the behaviour to existing prevailing convention, but now
> Git is older than X% of projects that use Git where the number X is
> a pretty large number.  Perhaps just like they (whichever mailing
> lists they are) switched out of Subversion or CVS and started using
> Git to come to the modern world, maybe it is time they switch their
> convention as well?
Well, the only mailing-list I saw this behavior is zsh. I did not dig
into its history to see when this behavior has been adopted. I did not
see remarks regarding patches sent with [PATCH], but I just wanted to
adopt the existing style rather than using a new one and thought that
git was already providing a way to do so, and eventually developed this
patch.

So, I do not know what to do now:
 - stick to [PATCH]
 - try one of the two first alternatives above (multiple options or
   implement conditionals)
 - re-work this patch by implementing the command line option, creating
   an other patch to use a configuration option, and hope it would be
   accepted because it makes sense to some people. The only advantage of
   using PATCH: rather than [PATCH] is that 1 char is saved :|. Making
   the subject less 'aggressive' is a feature but not necessarily an
   advantage.

Failing to see some interest for solutions 2 or 3, I would fall back to
solution 1 :).

Thanks,

Marc.