aboutsummaryrefslogtreecommitdiff
path: root/Documentation/SubmittingPatches
diff options
context:
space:
mode:
authorJonathan Nieder <jrnieder@gmail.com>2011-04-14 21:24:01 -0500
committerJunio C Hamano <gitster@pobox.com>2011-04-15 13:28:03 -0700
commit57756161eed50f2b52c9e32b01f6388814a09943 (patch)
treeb313b6b5d8c65f90e077787755b944f11ad7cb25 /Documentation/SubmittingPatches
parented44fd045a8a4bcf7f30a47e4fc6aba761faaf78 (diff)
downloadgit-57756161eed50f2b52c9e32b01f6388814a09943.tar.gz
git-57756161eed50f2b52c9e32b01f6388814a09943.tar.xz
Documentation: explain how to check for patch corruption
SubmittingPatches has some excellent advice about how to check a patch for corruption before sending it off. Move it to the format-patch manual so it can be installed with git's documentation for use by people not necessarily interested in the git project's practices. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/SubmittingPatches')
-rw-r--r--Documentation/SubmittingPatches58
1 files changed, 14 insertions, 44 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c6a503291..20b410147 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -344,50 +344,20 @@ MUA specific hints
Some of patches I receive or pick up from the list share common
patterns of breakage. Please make sure your MUA is set up
-properly not to corrupt whitespaces. Here are two common ones
-I have seen:
-
-* Empty context lines that do not have _any_ whitespace.
-
-* Non empty context lines that have one extra whitespace at the
- beginning.
-
-One test you could do yourself if your MUA is set up correctly is:
-
-* Send the patch to yourself, exactly the way you would, except
- To: and Cc: lines, which would not contain the list and
- maintainer address.
-
-* Save that patch to a file in UNIX mailbox format. Call it say
- a.patch.
-
-* Try to apply to the tip of the "master" branch from the
- git.git public repository:
-
- $ git fetch http://kernel.org/pub/scm/git/git.git master:test-apply
- $ git checkout test-apply
- $ git reset --hard
- $ git am a.patch
-
-If it does not apply correctly, there can be various reasons.
-
-* Your patch itself does not apply cleanly. That is _bad_ but
- does not have much to do with your MUA. Please rebase the
- patch appropriately.
-
-* Your MUA corrupted your patch; "am" would complain that
- the patch does not apply. Look at .git/rebase-apply/ subdirectory and
- see what 'patch' file contains and check for the common
- corruption patterns mentioned above.
-
-* While you are at it, check what are in 'info' and
- 'final-commit' files as well. If what is in 'final-commit' is
- not exactly what you would want to see in the commit log
- message, it is very likely that your maintainer would end up
- hand editing the log message when he applies your patch.
- Things like "Hi, this is my first patch.\n", if you really
- want to put in the patch e-mail, should come after the
- three-dash line that signals the end of the commit message.
+properly not to corrupt whitespaces.
+
+See the DISCUSSION section of git-format-patch(1) for hints on
+checking your patch by mailing it to yourself and applying with
+git-am(1).
+
+While you are at it, check the resulting commit log message from
+a trial run of applying the patch. If what is in the resulting
+commit is not exactly what you would want to see, it is very
+likely that your maintainer would end up hand editing the log
+message when he applies your patch. Things like "Hi, this is my
+first patch.\n", if you really want to put in the patch e-mail,
+should come after the three-dash line that signals the end of the
+commit message.
Pine