all 18 comments

sorted by: hot top controversial new old
[–] 36 points 9 months ago (13 children)

... if you have a super janky patch file workflow.

If you are using Git like normal people do this can't happen.

  • source
  • hideshow 13 child comments
  • [–] 23 points 9 months ago (12 children)

    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

  • source
  • parent
  • hideshow 12 child comments
  • [–] 9 points 9 months ago (4 children)

    Yeah it's mad. Tbh I don't think GitHub PRs are the best workflow, but I absolutely know that git send-email is 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...

  • source
  • parent
  • hideshow 4 child comments
  • [–] 4 points 9 months ago (3 children)

    Why didn't your patch get merged?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 5 points 9 months ago (2 children)

    They wanted me to make some changes and with the normal workflow that's just git commit and git push. With git send-email I have no fucking idea and it got beyond the point where I had enough cared enough to fight the process.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 9 months ago (5 children)

    I haven't heard of any projects but Linux and Git itself using this.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 5 points 9 months ago (4 children)

    Sourcehut uses it, it's actually the only way to interact with repos hosted on it.

    It definitely feels outdated, yet it's also how git is designed to work well with. Like git makes it really easy to re-write commit history, while also warning you not to force push re-written history to a public repo (Like e.g. a PR), that's because none of that is an issue with the email workflow, where each email is always an entirely isolated new commit.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 9 months ago (2 children)

    It definitely feels outdated

    What, why?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 9 months ago (1 child)

    Compared to e.g. pushing a button in VS code and having your browser pop up with a pre-filled in github PR page? It's clunky, but that doesn't mean it's not useful.

    For starters it's entirely decentralised, a single email address is all you need to commit to anything, regardless of where and how it's hosted. There was actually an article on lobsters recently that I thought was quite neat, how the combination of a patch-based workflow and email allows for entirely offline development, something that's simply not possible with things like github or codeberg.

    https://ploum.net/2026-01-31-offline-git-send-email.html

    The fact that you can "send" an email without actually sending it means you can queue the patch submissions up offline and then send them whenever you're ready, along with downloading the replies.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 11 points 9 months ago*

    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-am should use a better file format, but I suppose the more realistic lesson now is to never have inline diffs in Commit messages.

  • source
  • [–] 9 points 9 months ago (1 child)

    Context: this happens if you use patch(1) with patches generated by git format-patch. If you do, you should be using git am instead.

  • source
  • hideshow 1 child comment
  • load more comments (-1 replies)