… if you have a super janky patch file workflow.
If you are using Git like normal people do this can’t happen.
The Linux kernel development workflow, the purpose for which git was invented, makes use of emailed patches https://docs.kernel.org/process/submitting-patches.html
Yeah it’s mad. Tbh I don’t think GitHub PRs are the best workflow, but I absolutely know that
git send-emailis the worst. I tried to use it once to contribute to OpenSBI, which inexplicably also insists on it. Suffice it to say my patch was never merged…Why didn’t your patch get merged?
… which arguably makes them not “normal people” (referring to the earlier comment).
Surely, most people use different, more integrated tooling.
Hooray to underspecified file formats.
From
patch(1):patch tries to skip any leading garbage, apply the diff, and then skip any trailing garbage. Thus you could feed an email message containing a diff listing to patch, and it should work.
From
git-am(1):The patch is expected to be inline, directly following the message. Any line that is of the form:
- three-dashes and end-of-line, or
- a line that begins with “diff -”, or
- a line that begins with "Index: "
is taken as the beginning of a patch, and the commit log message is terminated before the first occurrence of such a line.
Ideally
git-amshould use a better file format, but I suppose the more realistic lesson now is to never have inline diffs in Commit messages.Context: this happens if you use
patch(1) with patches generated bygit format-patch. If you do, you should be usinggit aminstead.It happens when you use git-am as well, per the thread
Ha. Lol. That’s bad
The final verdict being “it’s working as intended” is fully wild to me.
