{"thread":{"id":"23517","subject":"[RFC PATCH 1/2] SubmittingPatches: Add new section about what to base work on","startedAt":"2010-04-18T19:54:20Z","lastAt":"2010-04-18T20:24:07Z","messageCount":2,"participants":["Ramkumar Ramachandra","Sverre Rabbelier"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"139840","messageId":"1271620400-sup-4850@kytes","threadId":"23517","inReplyTo":null,"subject":"[RFC PATCH 1/2] SubmittingPatches: Add new section about what to base work on","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-18T19:54:20Z","receivedAt":"2010-04-18T19:54:20Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Add a section 0 explaining which commit to base patches on. Rewrite a\ncouple of paragraphs about signing off patches to reflect Junio's\nupdated preferences.\n\nFrom: Junio C Hamano \nSigned-off-by: Ramkumar Ramachandra \n---\n Documentation/SubmittingPatches | 52 ++++++++++++++++++++++++++++++--------\n 1 files changed, 41 insertions(+), 11 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex abc65de..a90155c 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -53,6 +53,37 @@ But the patch submission requirements are a lot more relaxed\n here on the technical/contents front, because the core GIT is\n thousand times smaller ;-). So here is only the relevant bits.\n \n+(0) Decide what to base your work on.\n+\n+The general principle is always to base your work on the oldest branch\n+that your change is relevant to.\n+\n+ - A fix for a bug that has been with git from older releases should be\n+ included in both the upcoming feature release and the current\n+ maintenance release. Try to base your work on the 'maint' branch. A\n+ work to kill a bug that is in 'master' but not in 'maint' should be\n+ based on 'master'.\n+\n+ - A fix for a bug that is not yet in 'master' is the best bug to kill.\n+ If you can find the topic that introduces the regression, base your\n+ work on the tip of the topic. \"log --first-parent master..pu\" would be\n+ a good way to find the tips of topic branches.\n+\n+ - A new feature should be based on the 'master' branch in general.\n+\n+ - If your new feature depends on some other topics that are not in\n+ 'master' yet, and if it relies only on one topic, base your work on the\n+ tip of that topic. If it depends on too many topics that are not in\n+ 'master', you can privately start working on 'next' or even 'pu' and\n+ send out your patches for discussion, but it is possible that your\n+ maintainer may ask you to wait and rebase your changes on 'master'\n+ after some of the larger topics your topic depends on graduate to\n+ 'master'.\n+\n+ - Base corrections and enhancements on a topic that are not in 'master'\n+ yet but already merged to 'next' on the tip of the topic. If the topic\n+ has not been merged to 'next', it is Ok to add a note that the patch is\n+ a trivial fix and can be squashed into the series.\n \n (1) Make separate commits for logically separate changes.\n \n@@ -170,17 +201,16 @@ patch, format it as \"multipart/signed\", not a text/plain message\n that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is\n not a text/plain, it's something else.\n \n-Note that your maintainer does not necessarily read everything\n-on the git mailing list. If your patch is for discussion first,\n-send it \"To:\" the mailing list, and optionally \"cc:\" him. If it\n-is trivially correct or after the list reached a consensus, send\n-it \"To:\" the maintainer and optionally \"cc:\" the list for\n-inclusion.\n-\n-Also note that your maintainer does not actively involve himself in\n-maintaining what are in contrib/ hierarchy. When you send fixes and\n-enhancements to them, do not forget to \"cc: \" the person who primarily\n-worked on that hierarchy in contrib/.\n+Unless your patch is a very trivial and an obviously correct one,\n+first send it with \"To:\" set to the mailing list, with \"cc:\" listing\n+people who are involved in the area you are touching (the output from\n+\"git blame $path\" and \"git shortlog --no-merges $path\" would help to\n+identify them), to solicit comments and reviews. After the list\n+reached a consensus that it is a good idea to apply the patch, re-send\n+it with \"To:\" set to the maintainer and optionally \"cc:\" the list for\n+inclusion. Do not forget to add trailers such as \"Acked-by:\",\n+\"Reviewed-by:\" and \"Tested-by:\" after your \"Signed-off-by:\" line as\n+necessary.\n \n \n (4) Sign your work\n-- \n1.7.0.4\n"},{"id":"139844","messageId":"j2yfabb9a1e1004181324w759d6dcbs8a68a402b3b91a78@mail.gmail.com","threadId":"23517","inReplyTo":"1271620400-sup-4850@kytes","subject":"Re: [RFC PATCH 1/2] SubmittingPatches: Add new section about what to base work on","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-18T20:24:07Z","receivedAt":"2010-04-18T20:24:07Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Apr 18, 2010 at 21:54, Ramkumar Ramachandra wrote:\n> From: Junio C Hamano \n\nThat's my fault, I should have been more clear in that this should\nhave been at the top of the message :). Either way, the idea (that\nthis patch was a literal re-send of Junio's patch) was conveyed\nsuccessfully I think.\n\n-- \nCheers,\n\nSverre Rabbelier\n"}]}