Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > Playing devil's advocate for a minute, is this really common enough to > justify a new option when the user can use "--subject-prefix='PATCH > RESEND'" instead? The same applies to "--rfc", but the justification goes like this. * When you are working on a single subsystem in a larger project, your patches would want to carry the subsystem name. You'd use "--subject-prefix='PATCH frotz'" (and more likely it comes from format.subjectPrefix in a working repository dedicated to work on the frotz subsystem) for that. * In the context of working on that subsystem, sometimes you would need to mark your patch as a RFC patch, i.e., "[RFC PATCH frotz]", and that is done per-invocation basis (i.e., you are not always constantly sending an RFC) with "--rfc". Having orthogonal two mechanisms whose results are concatenated together is handy than having to specify the whole thing. I somehow thought that during the review of the "--rfc" option a few ideas were brought up to deal with adornments other than but similar to RFC. I still think the approach to make "--rfc" take an optional value, e.g., "--rfc=WIP" from the repository working in "frotz" subsystem would produce "[WIP PATCH frotz v2 2/4]" a reasonable one. cf. https://lore.kernel.org/git/xmqqbkepep9k.fsf@gitster.g/ Thanks.
