Removed by mod
… 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
… which arguably makes them not “normal people” (referring to the earlier comment).
Surely, most people use different, more integrated tooling.
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?
They wanted me to make some changes and with the normal workflow that’s just
git commitandgit push. Withgit send-emailI have no fucking idea and it got beyond the point where I had enough cared enough to fight the process.
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.
