This has come up multiple times before [1], and more generally it's come up hundreds of times with Unix style tools in general. It's always been a stupid idea for every tool to have its own barely documented file format.
This wouldn't be an issue if patches were XML or JSON with a well defined schema, but everything must be a boutique undocumented format in the world of Unix tools.
Maybe the worst part about this is that it can entirely come from a patch being exported by git and then imported straight back in to git. If you can't even handle your own undocumented format then what hope do other tools have that want to work with it?
> This wouldn't be an issue if patches were XML or JSON with a well defined schema, but everything must be a boutique undocumented format in the world of Unix tools.
Patch files are readable by humans. Replacing them with XML or JSON would fix this problem, but at the expense of removing a core feature.
syntheticnature · 2026-04-28 19:47:30 UTC
Haha, good one. Much like Makefiles, patch format precedes a lot of more modern things (by decades!) and is good enough to stick around. Unlike Makefiles, I've never seen tool gain any acceptance at all to replace patch.
tetha · 2026-04-28 20:50:12 UTC
And a lot of these older tools are not meant to be fed untrusted, unvetted input. The patch shown there confused me for quite a bit.
Or, more snarky: tee is also a huge security problem if you pipe untrusted input into `tee -a /etc/passwd`, such as `curl | tee -a /etc/passwd`. Not many things are safe with a `curl |` in front of them. I think yes might be?
pwdisswordfishs · 2026-04-28 20:39:29 UTC
> This wouldn't be an issue if patches were XML or JSON
Or MIME, even.
kevin_thibedeau · 2026-04-28 20:51:31 UTC
Patch: 1985
SGML: 1986
chrishill89 · 2026-04-28 20:52:56 UTC
> Maybe the worst part about this is that it can entirely come from a patch being exported by git and then imported straight back in to git.
No one wants to apply diffs in commit messages. But some people use this technique via email:
Finally fix it
---
Changes in v2:
- Proper formatting
- Remove irrelevant typo fix
They’ve used the `---` commit message delimiter in the commit message itself so that everything after it won’t be applied by git-am(1). So that’s intentional loss of round tripping.
I would personally use Git notes instead though.
Finally fix it
---
Notes:
Changes in v2: ...
Groxx · 2026-04-28 19:44:33 UTC
Seems like this would probably be solved if github returned a patch file formatted like `git show` provides, specifically with the commit message indented? I do see that `git format-patch` doesn't do this indentation though.
In any case, agreed that it's not a great "feature" to use in-band signaling of when patch data starts, with no escaping. Confusion and misbehavior is pretty much guaranteed.
chrishill89 · 2026-04-28 20:10:03 UTC
git-am(1) (apply patches) delimits the commit message from the patch/diff by looking for (1) a line `---` or (2) a line that starts with `diff -` or (3) a line that starts with `Index:SP` (SP is space). Only the first rule is necessary for patches generated git-format-patch(1). But git-am(1) is for applying patches, and you are free to bring patches from some other system. That’s why, I suppose, there are multiple options.
This means that it will try to apply any unindented diffs in the commit message. But you’re fine if you indent the diff. (Newschool code fencers will have a worse time here.)
I imagine that this worked fine for changes that were authored by one person and submitted by another person via email, or by their friend, or by someone trying to resurrect a previous attempt at getting something upstreamed. Someone is likely to notice that examples diffs are getting applied. But it won’t work well at all if you are some software distributor who is using patch files to apply modifications to packages.
Recall that git-am(1) will not apply indented diffs. Well have a look at my GNU patch 2.7.6:
If the entire diff is indented by a consistent amount, if lines end in
CRLF, or if a diff is encapsulated one or more times by prepending "- "
to lines starting with "-" as specified by Internet RFC 934, this is
taken into account.
Some may say that patch(1) should work like a more straightforward importer. But I’ve been itching to point out something else.
Comments
This wouldn't be an issue if patches were XML or JSON with a well defined schema, but everything must be a boutique undocumented format in the world of Unix tools.
Maybe the worst part about this is that it can entirely come from a patch being exported by git and then imported straight back in to git. If you can't even handle your own undocumented format then what hope do other tools have that want to work with it?
[1]: https://mas.to/@zekjur/116022397626943871
Patch files are readable by humans. Replacing them with XML or JSON would fix this problem, but at the expense of removing a core feature.
Or, more snarky: tee is also a huge security problem if you pipe untrusted input into `tee -a /etc/passwd`, such as `curl | tee -a /etc/passwd`. Not many things are safe with a `curl |` in front of them. I think yes might be?
Or MIME, even.
No one wants to apply diffs in commit messages. But some people use this technique via email:
They’ve used the `---` commit message delimiter in the commit message itself so that everything after it won’t be applied by git-am(1). So that’s intentional loss of round tripping.I would personally use Git notes instead though.
In any case, agreed that it's not a great "feature" to use in-band signaling of when patch data starts, with no escaping. Confusion and misbehavior is pretty much guaranteed.
This means that it will try to apply any unindented diffs in the commit message. But you’re fine if you indent the diff. (Newschool code fencers will have a worse time here.)
I imagine that this worked fine for changes that were authored by one person and submitted by another person via email, or by their friend, or by someone trying to resurrect a previous attempt at getting something upstreamed. Someone is likely to notice that examples diffs are getting applied. But it won’t work well at all if you are some software distributor who is using patch files to apply modifications to packages.
Recall that git-am(1) will not apply indented diffs. Well have a look at my GNU patch 2.7.6:
Some may say that patch(1) should work like a more straightforward importer. But I’ve been itching to point out something else. Is it surprising if patch(1) is a bit DWIM?