|
| 1 | +Patches produced by linkgit:git-format-patch[1] or |
| 2 | +linkgit:git-send-email[1] are inline. This means that the output of |
| 3 | +these two commands can lead to a different commit message when applied |
| 4 | +with linkgit:git-am[1]. It can also mean that the patch is not applied |
| 5 | +correctly. |
| 6 | + |
| 7 | +The commit message might contain a three-dash line (`---`) which was |
| 8 | +perhaps meant to be a thematic break. That means that the commit message |
| 9 | +will be cut short. The presence of a line starting with "Index: " can |
| 10 | +cause the patch not to be found, giving an error about an empty patch. |
| 11 | + |
| 12 | +Furthermore, the presence of an unindented diff in the commit message |
| 13 | +will not only cut the message short but cause that very diff to be |
| 14 | +applied, along with the patch in the patch section. The commit message |
| 15 | +might for example have a diff in a GitHub MarkDown code fence: |
| 16 | + |
| 17 | +---- |
| 18 | +``` |
| 19 | +diff ... |
| 20 | +``` |
| 21 | +---- |
| 22 | + |
| 23 | +The solution for this is to indent the diff instead: |
| 24 | + |
| 25 | +---- |
| 26 | + diff ... |
| 27 | +---- |
| 28 | + |
| 29 | +This loss of fidelity might be simple to notice if you are applying |
| 30 | +patches directly from a mailbox. However, a commit authored long ago |
| 31 | +might be applied in a different context, perhaps because many changes |
| 32 | +are being integrated via patch files and the |
| 33 | +linkgit:git-format-patch[1] format is trusted to import changes of a |
| 34 | +Git origin. |
| 35 | + |
| 36 | +One might want to use a general-purpose utility like patch(1) instead, |
| 37 | +given these limitations. However, patch(1) will not only look for |
| 38 | +unindented diffs (like linkgit:git-am[1]) but will try to apply indented |
| 39 | +diffs as well. |
0 commit comments