Marc Finet <m.dreadlock@xxxxxxxxx> 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. - 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. 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html