{"thread":{"id":"44102","subject":"[PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","startedAt":"2016-09-17T07:22:12Z","lastAt":"2016-09-20T06:51:40Z","messageCount":14,"participants":["Josh Triplett","Jeff King","Andrew Donnellan","Junio C Hamano","Jacob Keller"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"302098","messageId":"b5bf39015fdd20dd0aa4f38eb365bbbd0d07a4ca.1474096535.git-series.josh@joshtriplett.org","threadId":"44102","inReplyTo":null,"subject":"[PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-09-17T07:21:52Z","receivedAt":"2016-09-17T07:22:12Z","isPatch":true,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"This provides a shorter and more convenient alias for\n--subject-prefix='RFC PATCH'.\n\nIncludes documentation in the format-patch manpage, and a new test\ncovering --rfc.\n\nSigned-off-by: Josh Triplett \n---\nv2:\n- Add documentation to the format-patch manpage\n- Call subject_prefix_callback rather than reimplementing it\n- Update test to move expectations inside\n\n Documentation/git-format-patch.txt | 8 +++++++-\n builtin/log.c | 8 ++++++++\n t/t4014-format-patch.sh | 9 +++++++++\n 3 files changed, 24 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex 9624c84..b9590a5 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -19,7 +19,8 @@ SYNOPSIS\n \t\t [--start-number ] [--numbered-files]\n \t\t [--in-reply-to=Message-Id] [--suffix=.]\n \t\t [--ignore-if-in-upstream]\n-\t\t [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) ]\n+\t\t [--rfc] [--subject-prefix=Subject-Prefix]\n+\t\t [(--reroll-count|-v) ]\n \t\t [--to=] [--cc=]\n \t\t [--[no-]cover-letter] [--quiet] [--notes[=]]\n \t\t []\n@@ -172,6 +173,11 @@ will want to ensure that threading is disabled for `git send-email`.\n \tallows for useful naming of a patch series, and can be\n \tcombined with the `--numbered` option.\n \n+--rfc::\n+\tAlias for `--subject-prefix=\"RFC PATCH\"`. Use this when\n+\tsending an experimental patch for discussion rather than\n+\tapplication.\n+\n -v ::\n --reroll-count=::\n \tMark the series as the -th iteration of the topic. The\ndiff --git a/builtin/log.c b/builtin/log.c\nindex 92dc34d..5757d91 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -1112,6 +1112,11 @@ static int subject_prefix_callback(const struct option *opt, const char *arg,\n \treturn 0;\n }\n \n+static int rfc_callback(const struct option *opt, const char *arg, int unset)\n+{\n+\treturn subject_prefix_callback(opt, \"RFC PATCH\", unset);\n+}\n+\n static int numbered_cmdline_opt = 0;\n \n static int numbered_callback(const struct option *opt, const char *arg,\n@@ -1419,6 +1424,9 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \t\t\t N_(\"start numbering patches at instead of 1\")),\n \t\tOPT_INTEGER('v', \"reroll-count\", &reroll_count,\n \t\t\t N_(\"mark the series as Nth re-roll\")),\n+\t\t{ OPTION_CALLBACK, 0, \"rfc\", &rev, NULL,\n+\t\t\t N_(\"Use [RFC PATCH] instead of [PATCH]\"),\n+\t\t\t PARSE_OPT_NOARG | PARSE_OPT_NONEG, rfc_callback },\n \t\t{ OPTION_CALLBACK, 0, \"subject-prefix\", &rev, N_(\"prefix\"),\n \t\t\t N_(\"Use [] instead of [PATCH]\"),\n \t\t\t PARSE_OPT_NONEG, subject_prefix_callback },\ndiff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh\nindex b0579dd..ed4d3c2 100755\n--- a/t/t4014-format-patch.sh\n+++ b/t/t4014-format-patch.sh\n@@ -1073,6 +1073,15 @@ test_expect_success 'empty subject prefix does not have extra space' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success '--rfc' '\n+\tcat >expect <<-\\EOF &&\n+\tSubject: [RFC PATCH 1/1] header with . in it\n+\tEOF\n+\tgit format-patch -n -1 --stdout --rfc >patch &&\n+\tgrep ^Subject: patch >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_expect_success '--from=ident notices bogus ident' '\n \ttest_must_fail git format-patch -1 --stdout --from=foo >patch\n '\n\nbase-commit: 6ebdac1bab966b720d776aa43ca188fe378b1f4b\n-- \ngit-series 0.8.10\n"},{"id":"302106","messageId":"20160917184304.w7lzzsi7pxpnh5sr@sigill.intra.peff.net","threadId":"44102","inReplyTo":"b5bf39015fdd20dd0aa4f38eb365bbbd0d07a4ca.1474096535.git-series.josh@joshtriplett.org","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-09-17T18:43:04Z","receivedAt":"2016-09-17T18:43:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 17, 2016 at 12:21:52AM -0700, Josh Triplett wrote:\n\n> This provides a shorter and more convenient alias for\n> --subject-prefix='RFC PATCH'.\n> \n> Includes documentation in the format-patch manpage, and a new test\n> covering --rfc.\n> \n> Signed-off-by: Josh Triplett \n> ---\n> v2:\n> - Add documentation to the format-patch manpage\n> - Call subject_prefix_callback rather than reimplementing it\n> - Update test to move expectations inside\n\nAssuming we want this option, the implementation looks good to me (and I\ndon't have a big opinion the first part of that sentence).\n\n-Peff\n"},{"id":"302122","messageId":"3df15bbb-7eac-86ec-2ccb-74a973482e8c@au1.ibm.com","threadId":"44102","inReplyTo":"b5bf39015fdd20dd0aa4f38eb365bbbd0d07a4ca.1474096535.git-series.josh@joshtriplett.org","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Andrew Donnellan","fromEmail":"andrew.donnellan@au1.ibm.com","sentAt":"2016-09-19T09:17:28Z","receivedAt":"2016-09-19T09:17:42Z","isPatch":true,"sender":{"key":"andrew.donnellan@au1.ibm.com","avatar":null},"body":"On 17/09/16 17:21, Josh Triplett wrote:\n> This provides a shorter and more convenient alias for\n> --subject-prefix='RFC PATCH'.\n>\n> Includes documentation in the format-patch manpage, and a new test\n> covering --rfc.\n>\n> Signed-off-by: Josh Triplett \n\nSounds good to me. Agreed that \"RFC\" is essentially the only prefix \nother than \"PATCH\" that I see, at least in the kernel.\n\nI don't have anything to say about the code, though I did note that \nthere's a error message stating that \"--subject-prefix and -k are \nmutually exclusive.\" - I haven't tested the patch, but I imagine this \nmessage will trigger with --rfc as well and could be slightly confusing.\n\n> ---\n> v2:\n> - Add documentation to the format-patch manpage\n> - Call subject_prefix_callback rather than reimplementing it\n> - Update test to move expectations inside\n>\n> Documentation/git-format-patch.txt | 8 +++++++-\n> builtin/log.c | 8 ++++++++\n> t/t4014-format-patch.sh | 9 +++++++++\n> 3 files changed, 24 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\n> index 9624c84..b9590a5 100644\n> --- a/Documentation/git-format-patch.txt\n> +++ b/Documentation/git-format-patch.txt\n> @@ -19,7 +19,8 @@ SYNOPSIS\n> \t\t [--start-number ] [--numbered-files]\n> \t\t [--in-reply-to=Message-Id] [--suffix=.]\n> \t\t [--ignore-if-in-upstream]\n> -\t\t [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) ]\n> +\t\t [--rfc] [--subject-prefix=Subject-Prefix]\n> +\t\t [(--reroll-count|-v) ]\n> \t\t [--to=] [--cc=]\n> \t\t [--[no-]cover-letter] [--quiet] [--notes[=]]\n> \t\t []\n> @@ -172,6 +173,11 @@ will want to ensure that threading is disabled for `git send-email`.\n> \tallows for useful naming of a patch series, and can be\n> \tcombined with the `--numbered` option.\n>\n> +--rfc::\n> +\tAlias for `--subject-prefix=\"RFC PATCH\"`. Use this when\n> +\tsending an experimental patch for discussion rather than\n> +\tapplication.\n\nPerhaps mention the phrase \"Request For Comment\" for the benefit of \nthose who aren't familiar (which admittedly, among users of \ngit-format-patch, are probably rather few, but still).\n\n-- \nAndrew Donnellan OzLabs, ADL Canberra\nandrew.donnellan@au1.ibm.com IBM Australia Limited\n\n"},{"id":"302157","messageId":"xmqqa8f3g4pu.fsf@gitster.mtv.corp.google.com","threadId":"44102","inReplyTo":"3df15bbb-7eac-86ec-2ccb-74a973482e8c@au1.ibm.com","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-19T17:49:17Z","receivedAt":"2016-09-19T17:49:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Donnellan writes:\n\n> Sounds good to me. Agreed that \"RFC\" is essentially the only prefix\n> other than \"PATCH\" that I see, at least in the kernel.\n\nAround here I think we saw WIP too, and that makes me lean towards\nPeff's earlier suggestion to allow an end-user supplied string in\nfront of PATCH, i.e. \"-P RFC\" => \"--subject-prefix='RFC PATCH'\",\neven though I understand that those who _ONLY_ care about RFC would\nprefer --rfc (5 keystrokes) over \"-P RFC\" (6 keystrokes).\n\n>> +--rfc::\n>> +\tAlias for `--subject-prefix=\"RFC PATCH\"`. Use this when\n>> +\tsending an experimental patch for discussion rather than\n>> +\tapplication.\n>\n> Perhaps mention the phrase \"Request For Comment\" for the benefit of\n> those who aren't familiar ...\n\nGood point.\n"},{"id":"302183","messageId":"20160919204408.GA28962@cloud","threadId":"44102","inReplyTo":"xmqqa8f3g4pu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-09-19T20:44:08Z","receivedAt":"2016-09-19T20:44:16Z","isPatch":true,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Mon, Sep 19, 2016 at 10:49:17AM -0700, Junio C Hamano wrote:\n> Andrew Donnellan writes:\n> \n> > Sounds good to me. Agreed that \"RFC\" is essentially the only prefix\n> > other than \"PATCH\" that I see, at least in the kernel.\n> \n> Around here I think we saw WIP too, and that makes me lean towards\n> Peff's earlier suggestion to allow an end-user supplied string in\n> front of PATCH, i.e. \"-P RFC\" => \"--subject-prefix='RFC PATCH'\",\n> even though I understand that those who _ONLY_ care about RFC would\n> prefer --rfc (5 keystrokes) over \"-P RFC\" (6 keystrokes).\n\nI do share the concern raised elsewhere in the thread that adding new\nformat-patch short options potentially conflicts with diff/rev-list\nshort options. If you're not worried about that, I'd be happy to add\n(and document and test) -P. However, I'd still advocate adding --rfc as\nwell; it's a common case, and \"-P RFC\" is actually rather more\nkeystrokes when you count shifting. :)\n\nThere might also be some value in steering people towards \"RFC\" (since a\nWIP is in a way an RFC).\n\n> >> +--rfc::\n> >> +\tAlias for `--subject-prefix=\"RFC PATCH\"`. Use this when\n> >> +\tsending an experimental patch for discussion rather than\n> >> +\tapplication.\n> >\n> > Perhaps mention the phrase \"Request For Comment\" for the benefit of\n> > those who aren't familiar ...\n> \n> Good point.\n\nI'll add that to the documentation in v3.\n"},{"id":"302199","messageId":"20160919233434.fhkikksi4cxzrzb5@sigill.intra.peff.net","threadId":"44102","inReplyTo":"20160919204408.GA28962@cloud","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-09-19T23:34:35Z","receivedAt":"2016-09-19T23:34:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 19, 2016 at 01:44:08PM -0700, Josh Triplett wrote:\n\n> On Mon, Sep 19, 2016 at 10:49:17AM -0700, Junio C Hamano wrote:\n> > Andrew Donnellan writes:\n> > \n> > > Sounds good to me. Agreed that \"RFC\" is essentially the only prefix\n> > > other than \"PATCH\" that I see, at least in the kernel.\n> > \n> > Around here I think we saw WIP too, and that makes me lean towards\n> > Peff's earlier suggestion to allow an end-user supplied string in\n> > front of PATCH, i.e. \"-P RFC\" => \"--subject-prefix='RFC PATCH'\",\n> > even though I understand that those who _ONLY_ care about RFC would\n> > prefer --rfc (5 keystrokes) over \"-P RFC\" (6 keystrokes).\n> \n> I do share the concern raised elsewhere in the thread that adding new\n> format-patch short options potentially conflicts with diff/rev-list\n> short options. If you're not worried about that, I'd be happy to add\n> (and document and test) -P. However, I'd still advocate adding --rfc as\n> well; it's a common case, and \"-P RFC\" is actually rather more\n> keystrokes when you count shifting. :)\n> \n> There might also be some value in steering people towards \"RFC\" (since a\n> WIP is in a way an RFC).\n\nGood point. This may be an opportunity to be just slightly opinionated\nand nudge people towards a micro-standard.\n\nI was curious what we have used over the years on the git list. So here\nare the top hits for:\n\n # start with a maildir archive\n find git/cur -type f |\n\n # grab first subject line from each mail\n xargs grep -i -m1 -h ^subject: |\n\n # pull out only bracketed text, ignore \"re: [PATCH]\"\n perl -lne '/subject:\\s*(\\[.*?\\])/i and print $1' |\n\n # normalize numbers; note that a long patch series will be\n # over-represented, since it gets one hit per message\n perl -pe 's/[0-9]+/X/g' |\n\n # and then sort by count\n sort | uniq -c | sort -rn\n\nThe top 5 hits are:\n\n 26252 [PATCH X/X]\n 18255 [PATCH]\n 17262 [PATCH vX X/X]\n 2330 [PATCH vX]\n 2297 [PATCHvX X/X]\n\nwhich is not surprising (our \"-v\" uses \"PATCH vX\", which is why that's\nso much more common). After that it starts to get interesting, but let's\ndo two further transformations before the sort to coalesce similar\ncases:\n\n # drop versioning entirely\n perl -pe 's/\\s*vX//' |\n\n # drop multipart subjects\n perl -pe 's{\\s*X/X}{}' |\n\nThat gives us:\n\n 67081 [PATCH]\n 1286 [PATCH/RFC]\n 1169 [RFC/PATCH]\n 863 [JGIT PATCH]\n 832 [ANNOUNCE]\n 797 [RFC]\n 675 [RFC PATCH]\n 537 [StGit PATCH]\n 524 [EGIT PATCH]\n 367 [BUG]\n 169 [StGIT PATCH]\n 158 [GUILT]\n 142 [PATCH RFC]\n 131 [WIP PATCH]\n 129 [PATCH/WIP]\n 115 [TopGit PATCH]\n 115 [PATCH VX]\n ...\n\nSome of those are obviously uninteresting (like \"ANNOUNCE\" or \"BUG\").\nBut I see a few interesting patterns:\n\n - the \"slash\" form of RFC/PATCH or PATCH/RFC seems more common than a\n straight prefix (2400 versus about 800)\n\n - both RFC/PATCH and PATCH/RFC seems similarly popular (but \"RFC\n PATCH\" is much more popular than \"PATCH RFC\")\n\n - WIP is a lot less popular; it seems reasonable that it's a synonym\n for RFC and I don't mind pushing people in that direction\n\n - there are a non-trivial number of patches for other projects (JGIT,\n EGIT, StGit, etc). This is somewhat unique to git, where we discuss\n a lot of related projects on the list. But I wonder if other\n projects would use subsystems in a similar way (though I guess for\n the kernel, there are separate subsystems lists, so the \"to\" or \"cc\"\n header becomes the more interesting tag).\n\nSo I dunno what all this means. I do think \"--rfc\" to standardize on\n_some_ form of \"RFC PATCH\" or \"PATCH/RFC\" would serve the most people,\nand would make things more consistent. But at least in Git, people would\nbe served by having arbitrary prefixes, too.\n\nI don't have a big opinion on ordering or slashes. The slashes make\nsense to me as \"this is a patch, and it has these attribute tags\" (so\nwe could even start saying \"PATCH/maint\" or something, I guess). And\n\"RFC\" functions as such a tag. But for subsystems, putting the tag first\nis probably best; I don't care about EGIT patches, so I can immediately\nignore them when it's at the beginning.\n\nAs far as your patch goes, I'd be OK with defining:\n\n --rfc::\n\tPretend as if `--subject-prefix='RFC PATCH'` was given.\n\nfor now. If we later add:\n\n -P ::\n\tPretend as if `--subject-prefix=' PATCH'` was given.\n\nthen `--rfc` naturally becomes:\n\n --rfc::\n\tPretend as if `-P RFC` was given.\n\nin a backwards-compatible way. It doesn't have to all come at once, and\nit sounds like `-P` may not be as useful for the kernel (though I'd be\ninterested if somebody wanted to do a similar count; I don't have a copy\nof the kernel archive handy).\n\n-Peff\n\nPS There are some amusing ones as you get far down the list, like \"DRY\n HUMOR PATCH\". Clearly we need \"-P\" to encourage such things. :)\n"},{"id":"302200","messageId":"20160919234022.GA29421@cloud","threadId":"44102","inReplyTo":"20160919233434.fhkikksi4cxzrzb5@sigill.intra.peff.net","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-09-19T23:40:22Z","receivedAt":"2016-09-19T23:40:30Z","isPatch":true,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote:\n> On Mon, Sep 19, 2016 at 01:44:08PM -0700, Josh Triplett wrote:\n> \n> > On Mon, Sep 19, 2016 at 10:49:17AM -0700, Junio C Hamano wrote:\n> > > Andrew Donnellan writes:\n> > > \n> > > > Sounds good to me. Agreed that \"RFC\" is essentially the only prefix\n> > > > other than \"PATCH\" that I see, at least in the kernel.\n> > > \n> > > Around here I think we saw WIP too, and that makes me lean towards\n> > > Peff's earlier suggestion to allow an end-user supplied string in\n> > > front of PATCH, i.e. \"-P RFC\" => \"--subject-prefix='RFC PATCH'\",\n> > > even though I understand that those who _ONLY_ care about RFC would\n> > > prefer --rfc (5 keystrokes) over \"-P RFC\" (6 keystrokes).\n> > \n> > I do share the concern raised elsewhere in the thread that adding new\n> > format-patch short options potentially conflicts with diff/rev-list\n> > short options. If you're not worried about that, I'd be happy to add\n> > (and document and test) -P. However, I'd still advocate adding --rfc as\n> > well; it's a common case, and \"-P RFC\" is actually rather more\n> > keystrokes when you count shifting. :)\n> > \n> > There might also be some value in steering people towards \"RFC\" (since a\n> > WIP is in a way an RFC).\n> \n> Good point. This may be an opportunity to be just slightly opinionated\n> and nudge people towards a micro-standard.\n> \n> I was curious what we have used over the years on the git list. So here\n> are the top hits for:\n> \n> # start with a maildir archive\n> find git/cur -type f |\n> \n> # grab first subject line from each mail\n> xargs grep -i -m1 -h ^subject: |\n> \n> # pull out only bracketed text, ignore \"re: [PATCH]\"\n> perl -lne '/subject:\\s*(\\[.*?\\])/i and print $1' |\n> \n> # normalize numbers; note that a long patch series will be\n> # over-represented, since it gets one hit per message\n> perl -pe 's/[0-9]+/X/g' |\n> \n> # and then sort by count\n> sort | uniq -c | sort -rn\n> \n> The top 5 hits are:\n> \n> 26252 [PATCH X/X]\n> 18255 [PATCH]\n> 17262 [PATCH vX X/X]\n> 2330 [PATCH vX]\n> 2297 [PATCHvX X/X]\n> \n> which is not surprising (our \"-v\" uses \"PATCH vX\", which is why that's\n> so much more common). After that it starts to get interesting, but let's\n> do two further transformations before the sort to coalesce similar\n> cases:\n> \n> # drop versioning entirely\n> perl -pe 's/\\s*vX//' |\n> \n> # drop multipart subjects\n> perl -pe 's{\\s*X/X}{}' |\n> \n> That gives us:\n> \n> 67081 [PATCH]\n> 1286 [PATCH/RFC]\n> 1169 [RFC/PATCH]\n> 863 [JGIT PATCH]\n> 832 [ANNOUNCE]\n> 797 [RFC]\n> 675 [RFC PATCH]\n> 537 [StGit PATCH]\n> 524 [EGIT PATCH]\n> 367 [BUG]\n> 169 [StGIT PATCH]\n> 158 [GUILT]\n> 142 [PATCH RFC]\n> 131 [WIP PATCH]\n> 129 [PATCH/WIP]\n> 115 [TopGit PATCH]\n> 115 [PATCH VX]\n> ...\n> \n> Some of those are obviously uninteresting (like \"ANNOUNCE\" or \"BUG\").\n> But I see a few interesting patterns:\n> \n> - the \"slash\" form of RFC/PATCH or PATCH/RFC seems more common than a\n> straight prefix (2400 versus about 800)\n> \n> - both RFC/PATCH and PATCH/RFC seems similarly popular (but \"RFC\n> PATCH\" is much more popular than \"PATCH RFC\")\n> \n> - WIP is a lot less popular; it seems reasonable that it's a synonym\n> for RFC and I don't mind pushing people in that direction\n> \n> - there are a non-trivial number of patches for other projects (JGIT,\n> EGIT, StGit, etc). This is somewhat unique to git, where we discuss\n> a lot of related projects on the list. But I wonder if other\n> projects would use subsystems in a similar way (though I guess for\n> the kernel, there are separate subsystems lists, so the \"to\" or \"cc\"\n> header becomes the more interesting tag).\n\nThe kernel mostly uses \"[PATCH] subsystem: ...\". Occasionally I see\n\"[PATCH somegitrepo ...] ...\" when it's necessary to explicitly say\nwhose git repo the patch needs to go through, but that's pretty rare.\n\n> As far as your patch goes, I'd be OK with defining:\n> \n> --rfc::\n> \tPretend as if `--subject-prefix='RFC PATCH'` was given.\n> \n> for now. If we later add:\n> \n> -P ::\n> \tPretend as if `--subject-prefix=' PATCH'` was given.\n> \n> then `--rfc` naturally becomes:\n> \n> --rfc::\n> \tPretend as if `-P RFC` was given.\n> \n> in a backwards-compatible way. It doesn't have to all come at once, and\n> it sounds like `-P` may not be as useful for the kernel (though I'd be\n> interested if somebody wanted to do a similar count; I don't have a copy\n> of the kernel archive handy).\n\nSounds reasonable to me. I'll send v3 of --rfc with the requested\nadditional documentation fix, then.\n"},{"id":"302201","messageId":"CA+P7+xoGNEYbMKom5yqVDfMcyb1nJyP5nrQoRbWjGkPffyM+AQ@mail.gmail.com","threadId":"44102","inReplyTo":"20160919233434.fhkikksi4cxzrzb5@sigill.intra.peff.net","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-09-19T23:44:24Z","receivedAt":"2016-09-19T23:44:50Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, Sep 19, 2016 at 4:34 PM, Jeff King wrote:\n> - there are a non-trivial number of patches for other projects (JGIT,\n> EGIT, StGit, etc). This is somewhat unique to git, where we discuss\n> a lot of related projects on the list. But I wonder if other\n> projects would use subsystems in a similar way (though I guess for\n> the kernel, there are separate subsystems lists, so the \"to\" or \"cc\"\n> header becomes the more interesting tag).\n\nWorking in the net-next community, we often use \"[net PATCH]\",\n\"[net-next] [PATCH]\", or even just replace \"PATCH\" with \"[net-next]\"\nand similar (though this is served just fine by --subject-prefix, and\nmay be an artifact caused because -P doesn't exist).\n\nFor the netdev, there are both \"net\" and \"net-next\" trees, and so\nthere is some need to distinguish between these. I prefer \"[net\nPATCH]\" style myself.\n\nI think --rfc is common enough to warrant its own tag, even if we add\n\"-P tag\" just because it encourages its use for whenever you want to\ncomment about a patch without necessarily wanting it immediately\napplied.\n\nI also happen to prefer \"RFC PATCH\" instead of \"PATCH/RFC\" but I think\nthat's mostly preference.\n\n>\n> So I dunno what all this means. I do think \"--rfc\" to standardize on\n> _some_ form of \"RFC PATCH\" or \"PATCH/RFC\" would serve the most people,\n> and would make things more consistent. But at least in Git, people would\n> be served by having arbitrary prefixes, too.\n>\n\nA general way to do this would be helpful, but i don't think it avoids\nthe usefulness of --rfc on its own.\n\nI know that some formats are also generated by tools such as stgit\nwhich has its own way to generate emails and doesn't use exactly the\nsame format as git.\n\nThanks,\nJake\n"},{"id":"302202","messageId":"CA+P7+xp-CupfFwQv+U-KNh4bxG9Mxkbfip5RJebKX9gjffoOsw@mail.gmail.com","threadId":"44102","inReplyTo":"20160919234022.GA29421@cloud","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-09-19T23:46:06Z","receivedAt":"2016-09-19T23:46:31Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, Sep 19, 2016 at 4:40 PM, Josh Triplett wrote:\n> On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote:\n>> As far as your patch goes, I'd be OK with defining:\n>>\n>> --rfc::\n>> Pretend as if `--subject-prefix='RFC PATCH'` was given.\n>>\n\nWould:\n\nShorthand for `--subject-prefix='RFC PATCH'`\n\nbe a better reading? I feel like using \"pretend\" is a bit weird here.\n\nThat being said, I'm not super strongly against it, but just find that\nit sounds weird for documentation.\n\nThanks,\nJake\n"},{"id":"302203","messageId":"20160919235550.GC29421@cloud","threadId":"44102","inReplyTo":"CA+P7+xp-CupfFwQv+U-KNh4bxG9Mxkbfip5RJebKX9gjffoOsw@mail.gmail.com","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2016-09-19T23:55:50Z","receivedAt":"2016-09-19T23:55:59Z","isPatch":true,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Mon, Sep 19, 2016 at 04:46:06PM -0700, Jacob Keller wrote:\n> On Mon, Sep 19, 2016 at 4:40 PM, Josh Triplett wrote:\n> > On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote:\n> >> As far as your patch goes, I'd be OK with defining:\n> >>\n> >> --rfc::\n> >> Pretend as if `--subject-prefix='RFC PATCH'` was given.\n> >>\n> \n> Would:\n> \n> Shorthand for `--subject-prefix='RFC PATCH'`\n> \n> be a better reading? I feel like using \"pretend\" is a bit weird here.\n\nMy patch used \"Alias for\"; if you prefer \"Shorthand for\" I'm\nindifferent. :)\n"},{"id":"302204","messageId":"CA+P7+xoKV+ffVxTK6vobuxJy1pZndr7KBLo=BLPc9xiNQgYrqg@mail.gmail.com","threadId":"44102","inReplyTo":"20160919235550.GC29421@cloud","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-09-19T23:57:09Z","receivedAt":"2016-09-19T23:57:35Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, Sep 19, 2016 at 4:55 PM, Josh Triplett wrote:\n> On Mon, Sep 19, 2016 at 04:46:06PM -0700, Jacob Keller wrote:\n>> On Mon, Sep 19, 2016 at 4:40 PM, Josh Triplett wrote:\n>> > On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote:\n>> >> As far as your patch goes, I'd be OK with defining:\n>> >>\n>> >> --rfc::\n>> >> Pretend as if `--subject-prefix='RFC PATCH'` was given.\n>> >>\n>>\n>> Would:\n>>\n>> Shorthand for `--subject-prefix='RFC PATCH'`\n>>\n>> be a better reading? I feel like using \"pretend\" is a bit weird here.\n>\n> My patch used \"Alias for\"; if you prefer \"Shorthand for\" I'm\n> indifferent. :)\n\nAlias seems fine to me.\n\nThanks,\nJake\n"},{"id":"302206","messageId":"20160920013704.7hk2creytmfrla6h@sigill.intra.peff.net","threadId":"44102","inReplyTo":"20160919234022.GA29421@cloud","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-09-20T01:37:04Z","receivedAt":"2016-09-20T01:37:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 19, 2016 at 04:40:22PM -0700, Josh Triplett wrote:\n\n> > - there are a non-trivial number of patches for other projects (JGIT,\n> > EGIT, StGit, etc). This is somewhat unique to git, where we discuss\n> > a lot of related projects on the list. But I wonder if other\n> > projects would use subsystems in a similar way (though I guess for\n> > the kernel, there are separate subsystems lists, so the \"to\" or \"cc\"\n> > header becomes the more interesting tag).\n> \n> The kernel mostly uses \"[PATCH] subsystem: ...\". Occasionally I see\n> \"[PATCH somegitrepo ...] ...\" when it's necessary to explicitly say\n> whose git repo the patch needs to go through, but that's pretty rare.\n\nWe do both. \"foo: blah\" is for subsystem \"foo\" of Git itself, but\nall-caps \"JGIT PATCH\" is \"this is not even for Git\". I don't know that\nthe kernel really has an equivalent.\n\n-Peff\n"},{"id":"302207","messageId":"20160920013731.ljmbs4vspcxgbvhu@sigill.intra.peff.net","threadId":"44102","inReplyTo":"20160919235550.GC29421@cloud","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-09-20T01:37:32Z","receivedAt":"2016-09-20T01:37:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 19, 2016 at 04:55:50PM -0700, Josh Triplett wrote:\n\n> On Mon, Sep 19, 2016 at 04:46:06PM -0700, Jacob Keller wrote:\n> > On Mon, Sep 19, 2016 at 4:40 PM, Josh Triplett wrote:\n> > > On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote:\n> > >> As far as your patch goes, I'd be OK with defining:\n> > >>\n> > >> --rfc::\n> > >> Pretend as if `--subject-prefix='RFC PATCH'` was given.\n> > >>\n> > \n> > Would:\n> > \n> > Shorthand for `--subject-prefix='RFC PATCH'`\n> > \n> > be a better reading? I feel like using \"pretend\" is a bit weird here.\n> \n> My patch used \"Alias for\"; if you prefer \"Shorthand for\" I'm\n> indifferent. :)\n\nOr maybe \"Act as if...\".\n\n-Peff\n"},{"id":"302217","messageId":"CA+P7+xoQSV99i0ntsw8P+p3K21FGCi9kkhqTq7tC3rSCMcLL5g@mail.gmail.com","threadId":"44102","inReplyTo":"20160920013704.7hk2creytmfrla6h@sigill.intra.peff.net","subject":"Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-09-20T06:50:58Z","receivedAt":"2016-09-20T06:51:40Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, Sep 19, 2016 at 6:37 PM, Jeff King wrote:\n> On Mon, Sep 19, 2016 at 04:40:22PM -0700, Josh Triplett wrote:\n>\n>> > - there are a non-trivial number of patches for other projects (JGIT,\n>> > EGIT, StGit, etc). This is somewhat unique to git, where we discuss\n>> > a lot of related projects on the list. But I wonder if other\n>> > projects would use subsystems in a similar way (though I guess for\n>> > the kernel, there are separate subsystems lists, so the \"to\" or \"cc\"\n>> > header becomes the more interesting tag).\n>>\n>> The kernel mostly uses \"[PATCH] subsystem: ...\". Occasionally I see\n>> \"[PATCH somegitrepo ...] ...\" when it's necessary to explicitly say\n>> whose git repo the patch needs to go through, but that's pretty rare.\n>\n> We do both. \"foo: blah\" is for subsystem \"foo\" of Git itself, but\n> all-caps \"JGIT PATCH\" is \"this is not even for Git\". I don't know that\n> the kernel really has an equivalent.\n>\n> -Peff\n\n[net] and [net-next] are for the *tree* not the subsystem of the tree.\n\nnet: also means the networking subsystem, but it's different you might\nhave a new feature and say\n\n[net-next PATCH v2] net: my awesome new feature.\n\nThanks,\nJake\n"}]}