{"thread":{"id":"45780","subject":"[PATCH] doc: update SubmittingPatches","startedAt":"2017-04-23T16:20:59Z","lastAt":"2017-04-24T02:36:35Z","messageCount":2,"participants":["René Genz","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"317563","messageId":"1492964264-29423-1-git-send-email-liebundartig@freenet.de","threadId":"45780","inReplyTo":null,"subject":"[PATCH] doc: update SubmittingPatches","fromName":"René Genz","fromEmail":"liebundartig@freenet.de","sentAt":"2017-04-23T16:17:44Z","receivedAt":"2017-04-23T16:20:59Z","isPatch":true,"sender":{"key":"liebundartig@freenet.de","avatar":"https://avatars.githubusercontent.com/u/18424198?v=4"},"body":"-use US English spelling\n-based on my own experience:\n * add commands used to contribute a patch\n * minor wording change for better readability\n\nThanks-to: Stefan Beller <sbeller@google.com>\n---\n Documentation/SubmittingPatches | 31 +++++++++++++++++++++++++------\n 1 file changed, 25 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex bc8ad00..ac027ba 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -51,7 +51,7 @@ If your description starts to get too long, that's a sign that you\n probably need to split up your commit to finer grained pieces.\n That being said, patches which plainly describe the things that\n help reviewers check the patch, and future maintainers understand\n-the code, are the most beautiful patches.  Descriptions that summarise\n+the code, are the most beautiful patches.  Descriptions that summarize\n the point in the subject well, and describe the motivation for the\n change, the approach taken by the change, and if relevant how this\n differs substantially from the prior version, are all good things\n@@ -87,7 +87,7 @@ patches separate from other documentation changes.\n Oh, another thing.  We are picky about whitespaces.  Make sure your\n changes do not trigger errors with the sample pre-commit hook shipped\n in templates/hooks--pre-commit.  To help ensure this does not happen,\n-run git diff --check on your changes before you commit.\n+run \"git diff --check\" on your changes before you commit.\n \n \n (2) Describe your changes well.\n@@ -111,10 +111,10 @@ Improve...\".\n \n The body should provide a meaningful commit message, which:\n \n-  . explains the problem the change tries to solve, iow, what is wrong\n+  . explains the problem the change tries to solve, i.e. what is wrong\n     with the current code without the change.\n \n-  . justifies the way the change solves the problem, iow, why the\n+  . justifies the way the change solves the problem, i.e. why the\n     result with the change is better.\n \n   . alternate solutions considered but discarded, if any.\n@@ -122,7 +122,7 @@ The body should provide a meaningful commit message, which:\n Describe your changes in imperative mood, e.g. \"make xyzzy do frotz\"\n instead of \"[This patch] makes xyzzy do frotz\" or \"[I] changed xyzzy\n to do frotz\", as if you are giving orders to the codebase to change\n-its behaviour.  Try to make sure your explanation can be understood\n+its behavior.  Try to make sure your explanation can be understood\n without external resources. Instead of giving a URL to a mailing list\n archive, summarize the relevant points of the discussion.\n \n@@ -261,7 +261,7 @@ smaller project it is a good discipline to follow it.\n The sign-off is a simple line at the end of the explanation for\n the patch, which certifies that you wrote it or otherwise have\n the right to pass it on as a open-source patch.  The rules are\n-pretty simple: if you can certify the below:\n+pretty simple: if you can certify the below D-C-O:\n \n         Developer's Certificate of Origin 1.1\n \n@@ -376,6 +376,25 @@ from the list and queue it to 'pu', in order to make it easier for\n people play with it without having to pick up and apply the patch to\n their trees themselves.\n \n+\n+An oversimplified summary of the commands to run:\n+* clone repo\n+  $ git clone https://github.com/git/git\n+\n+* change files in your local repo copy\n+\n+* commit your changes\n+  $ git commit -a\n+\n+* create '.patch' file for the latest commit\n+  $ git format-patch HEAD^\n+\n+* install 'git-email' package and configure it, f.e.\n+    https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/\n+  send an email to yourself using your MUA in order to find out the value\n+  for the \"--smtp-domain\" option; look at the 'Received' header option\n+  $ git send-email --annotate --smtp-domain=LONGSTRING --to=git@vger.kernel.org --cc=MAINTAINER --smtp-debug=1 NAME.patch\n+\n ------------------------------------------------\n Know the status of your patch after submission\n \n-- \n1.9.1\n\n"},{"id":"317631","messageId":"xmqq60hu351w.fsf@gitster.mtv.corp.google.com","threadId":"45780","inReplyTo":"1492964264-29423-1-git-send-email-liebundartig@freenet.de","subject":"Re: [PATCH] doc: update SubmittingPatches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-24T02:36:27Z","receivedAt":"2017-04-24T02:36:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Genz <liebundartig@freenet.de> writes:\n\n (updates for minor irritations skipped as I do not have strong\n opinions against them).\n\n> @@ -261,7 +261,7 @@ smaller project it is a good discipline to follow it.\n>  The sign-off is a simple line at the end of the explanation for\n>  the patch, which certifies that you wrote it or otherwise have\n>  the right to pass it on as a open-source patch.  The rules are\n> -pretty simple: if you can certify the below:\n> +pretty simple: if you can certify the below D-C-O:\n\nOK.  There is another instance of D-C-O away from here and new\npeople who read the document would not know without this addition\nwhat it refers to.  This is a good addition.\n\n>          Developer's Certificate of Origin 1.1\n>  \n> @@ -376,6 +376,25 @@ from the list and queue it to 'pu', in order to make it easier for\n>  people play with it without having to pick up and apply the patch to\n>  their trees themselves.\n\n\nAn oversimplified one is not necessarily welcome.  Can you split\nthis patch into \"fixes\" (all of the above) and the remainder?\n\n>  \n> +\n> +An oversimplified summary of the commands to run:\n\n> +* clone repo\n> +  $ git clone https://github.com/git/git\n> +\n> +* change files in your local repo copy\n> +\n> +* commit your changes\n> +  $ git commit -a\n> +\n> +* create '.patch' file for the latest commit\n> +  $ git format-patch HEAD^\n> +\n> +* install 'git-email' package and configure it, f.e.\n> +    https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/\n> +  send an email to yourself using your MUA in order to find out the value\n> +  for the \"--smtp-domain\" option; look at the 'Received' header option\n> +  $ git send-email --annotate --smtp-domain=LONGSTRING --to=git@vger.kernel.org --cc=MAINTAINER --smtp-debug=1 NAME.patch\n> +\n>  ------------------------------------------------\n>  Know the status of your patch after submission\n"}]}