34 lines
1.5 KiB
Plaintext
34 lines
1.5 KiB
Plaintext
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.
|