aboutsummaryrefslogtreecommitdiff
path: root/Documentation/git-format-patch.txt
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/git-format-patch.txt
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/git-format-patch.txt')
-rw-r--r--Documentation/git-format-patch.txt46
1 files changed, 46 insertions, 0 deletions
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 155b7ae3c..8bf6a6850 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -286,6 +286,52 @@ title is likely to be different from the subject of the discussion the
patch is in response to, so it is likely that you would want to keep
the Subject: line, like the example above.
+Checking for patch corruption
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Many mailers if not set up properly will corrupt whitespace. Here are
+two common types of corruption:
+
+* Empty context lines that do not have _any_ whitespace.
+
+* Non-empty context lines that have one extra whitespace at the
+ beginning.
+
+One way to test if your MUA is set up correctly is:
+
+* Send the patch to yourself, exactly the way you would, except
+ with To: and Cc: lines that do not contain the list and
+ maintainer address.
+
+* Save that patch to a file in UNIX mailbox format. Call it a.patch,
+ say.
+
+* Apply it:
+
+ $ git fetch <project> 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.
+
+* The patch itself does not apply cleanly. That is _bad_ but
+ does not have much to do with your MUA. You might want to rebase
+ the patch with linkgit:git-rebase[1] before regenerating it in
+ this case.
+
+* The MUA corrupted your patch; "am" would complain that
+ the patch does not apply. Look in the .git/rebase-apply/ subdirectory and
+ see what 'patch' file contains and check for the common
+ corruption patterns mentioned above.
+
+* While at it, check the '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 the
+ receiver would end up hand editing the log message when applying
+ your patch. Things like "Hi, this is my first patch.\n" in the
+ patch e-mail should come after the three-dash line that signals
+ the end of the commit message.
+
EXAMPLES
--------