← Back to context

Comment by quuxplusone

20 hours ago

> fake email headers

That's the output you get from `git format-patch --stdout -1 dd28283`. The idea is that it's suitable for emailing to a mailing list for review (hence the subject line beginning with [PATCH], and so on).

If you ask for colorized output with `git format-patch --color=always --stdout -1 dd28283` you'll see that `git format-patch` itself knows which bits are the commit message and which bits are the diff. (Well, of course it does, I guess.)

I suspect that if you sent a patch like this to the mailing list, they'd get mad at you. So `git format-patch` is working OK for its intended use-case. Arguably it's GitHub causing the problem here by "misusing" `git format-patch` as a way to deliver patches that are (these days) expected to be machine-readable — something you can just curl and pipe into `patch`. `git format-patch` doesn't do that.

That said, yeah, it's amusing that (as TFA says)

    git format-patch -1 HEAD --stdout > 0001 ;
    git checkout HEAD~ ;
    git am 0001

isn't a clean round-trip. `git am` applies the fake diff.

> If you think I can get you to patch inappropriate files by writing a fake diff into my commit message... wait until you see what I can do by writing those same changes into the real diff.

Well put. :)

2 comments

quuxplusone

Reply
quuxplusone  4 hours ago

jolmg points out that if you use a GitHub URL ending in .diff instead of .patch, you get something much more suitable to feed mechanically into `patch`. (And probably not so exploitable.)

Therefore I retract my claim that this is even a "misuse" of `git format-patch` by GitHub. Seems like GitHub provides both a git-am-able endpoint and a (less exploitable) patch-able endpoint, and the issue is just that OP chose the less suitable one of those two endpoints.