undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation: explain how to check for patch corruption

Browse Source 
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>
This commit is contained in:
Jonathan Nieder 2011-04-14 21:24:01 -05:00 committed by Junio C Hamano
parent ed44fd045a
commit 57756161ee
2 changed files with 58 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
Documentation/SubmittingPatches
View File

@ -344,50 +344,20 @@ MUA specific hints
Some of patches I receive or pick up from the list share common Some of patches I receive or pick up from the list share common
patterns of breakage. Please make sure your MUA is set up patterns of breakage. Please make sure your MUA is set up
properly not to corrupt whitespaces. Here are two common ones properly not to corrupt whitespaces.
I have seen:
* Empty context lines that do not have _any_ whitespace. 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).
* Non empty context lines that have one extra whitespace at the While you are at it, check the resulting commit log message from
beginning. 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
One test you could do yourself if your MUA is set up correctly is: likely that your maintainer would end up hand editing the log
message when he applies your patch. Things like "Hi, this is my
* Send the patch to yourself, exactly the way you would, except first patch.\n", if you really want to put in the patch e-mail,
To: and Cc: lines, which would not contain the list and should come after the three-dash line that signals the end of the
maintainer address. commit message.
* 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.
Pine Pine

46
Documentation/git-format-patch.txt
View File

@ -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 patch is in response to, so it is likely that you would want to keep
the Subject: line, like the example above. 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 EXAMPLES
-------- --------