| The output from linkgit:git-format-patch[1] can lead to a different | |
| commit message when applied with linkgit:git-am[1]. The patch that is | |
| applied may also be different from the one that was generated, or patch | |
| application may fail outright. | |
| ifdef::git-am[] | |
| See the <<discussion,DISCUSSION>> section above for the syntactic rules. | |
| endif::git-am[] | |
| ifndef::git-am[] | |
| include::format-patch-end-of-commit-message.adoc[] | |
| endif::git-am[] | |
| Note that this is especially problematic for unindented diffs that occur | |
| in the commit message; the diff in the commit message might get applied | |
| along with the patch section, or the patch application machinery might | |
| trip up because the patch target doesn't apply. This could for example | |
| be caused by a diff in a Markdown code block. | |
| The solution for this is to indent the diff or other text that could | |
| cause problems. | |
| This loss of fidelity might be simple to notice if you are applying | |
| patches directly from a mailbox. However, changes originating from Git | |
| could be applied in bulk, in which case this would be much harder to | |
| notice. This could for example be a Linux distribution which uses patch | |
| files to apply changes on top of the commits from the upstream | |
| repositories. This goes to show that this behavior does not only impact | |
| email workflows. | |
| Given these limitations, one might be tempted to use a general-purpose | |
| utility like `patch`(1) instead. However, `patch`(1) will not only look for | |
| unindented diffs (like linkgit:git-am[1]) but will try to apply indented | |
| diffs as well. |