5 ms·

This reminds me of Drew DeVault's advocacy for the traditional email-driven git workflow. [0][1] (Drew is the creator of SourceHut, an email-oriented git forge.

This reminds me of Drew DeVault's advocacy for the traditional email-driven git workflow. [0][1] (Drew is the creator of SourceHut, an email-oriented git forge.) I think his (Simon's) objection to git send-email emails could be addressed with better tooling, or better use of them. It's 'just' a matter of exporting the emails into a single mailbox file, right? (I'm not experienced with git's email-driven features.) It seems to work smoothly for the Linux kernel folks; clearly it doesn't have to be clunky. > because git format-patch doesn’t mention what commit the patches do apply against, I’m more likely to encounter a conflict in the first place when trying to apply them. This is what the --base flag is for. [2] [0] https://git-send-email.io/ https://git-send-email.io/ [1] https://git-am.io/ https://git-am.io/ [2] https://git-scm.com/docs/git-format-patch#Documentation/git-format-patch.txt---no-baseltcommitgt https://git-scm.com/docs/git-format-patch#Documentation/git-...

bjackman 2y ago
It doesn't work smoothly for Linux kernel folks. It's a huge pain in the arse to review code. Some subprojects have CI but mostly it's too much work to set it up. You never know if the code that gets merged is truly what got reviewed. Half the time if you wanna test out someone's patches you have to spend 20 minutes trying to figure out what base commit they even apply to. Old fashioned mail clients are huge pain to deal with (and mail servers? Fuck). Raw text with no concept of "review thread resolved" wastes loads of review energy manually tracking what feedback has or hasn't been addressed. Comparing old and new versions of a patchset (equivalent of a pull request) requires manually searching your mailbox for the different versions, manually applying them to your local repo (hopefully you can find the base commit the old version applies to, which by now might not even exist any more if it's an unstable maintainer branch) and then manually running git-range-diff. As someone who works with an git-send-email workflow every day, I can tell you, it sucks. Email is not a good substrate for development. If I were Linus I would be pestering the Linux Foundation to set up a bunch of managed Gerrit instances or something.
- imiric 2y ago
  Don't they have tooling to help with these issues? Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. This won't align with everyone's preferences, of course, but I can't imagine someone like Linus not being happy with it.
  - JoshTriplett 2y ago
    > Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. No, it really, really wouldn't. The Linux workflow is optimized for the preferences of (a subset of) maintainers, notably Linus; it is not optimized for contributors.
- karel-3d 2y ago
  The other guy got downvoted, but... isn't there really some tooling to help with this? Some standardized way of actually sending/reviewing the e-mails? sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...? One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! But I never had to actually use it.
  - bjackman 2y ago
    No there are no standardised tools. There is Patchwork which can help with managing the review workload and can also provide some CI feedback, some subsystems use that with some succcess, other's don't. It's not really something an individual can adopt so if you're working in an area that doesn't use it you're out of luck. There is also Patchew which I've never tried. But overall everyone just has their own individual pile of shell scrips and mail client macros.
    - imiric 2y ago
      > No there are no standardised tools. Why would you expect there to be a standardised set of tools used by the largest distributed project in the world? Do you think that this would be possible to enforce globally in a way that makes everyone happier to contribute? You mentioned two tools that are used by some subsystems. b4[1] is another one, and more are listed here[2]. So there _is_ tooling around it that works for many people. It's just not your preferred choice of tooling, which is... fine. The fact that email is the lowest common denominator seems like a good thing to me. It allows everyone to use their tools of choice. As long as you can send and receive email, you can contribute. How you decide to integrate that into your development process is up to you. If you can't be bothered to setup a workflow from scratch, then you can adopt someone else's. I'd much rather have this choice, than be forced to use Gerrit or GitHub or whatever else. [1]: https://b4.docs.kernel.org/ https://b4.docs.kernel.org/ [2]: https://www.kernel.org/doc/html/v6.14-rc4/dev-tools/index.html https://www.kernel.org/doc/html/v6.14-rc4/dev-tools/index.ht...
sneak 2y ago
Email, like nntp and gopher, lost to the web. People won’t use it if it ain’t on the web. If you force them to use it anyway, very few people will use it. DdV’s advocacy stems from the fact that he is a lone-wolf dev, building tooling for other lone-wolf devs. The social and collaborative features sucking is a feature, not a bug. It falls flat on its face for larger projects and communities.
- bigstrat2003 2y ago
  > If you force them to use it anyway, very few people will use it. And that's perfectly fine. Not all things are for all people, and nor should they even try to be.
- TylerE 2y ago
  See, I don't think it has much to do with not being on "the web" and everything to do with federated services actually being a terrible fit for most users most of the time, and not worth the headaches (e.g. spam, netsplits, missing posts...)
- specialist 2y ago
  Noob questions: PRs are public and email patches are receiver's inbox only, right? When I'm assessing the merit of any given project, I'd want see if there's a backlog of PRs, right? Do projects using email-patch workflows set up listservs for receiving patches?
  - MaxBarraclough 2y ago
    > PRs are public and email patches are receiver's inbox only, right? Not necessarily. For a 'lone wolf' project that might be the case, but some projects have public mailing-list archives, e.g. https://lists.gnu.org/archive/html/lightning/ https://lists.gnu.org/archive/html/lightning/ I think it would be necessary to do some manual copy+pasting, or else use custom scripts/tooling, to turn such mailing-list archive pages into patch files (for git apply) or mbox files (for git am).
cortesoft 2y ago
I think it is funny to think of the email-driven git workflow as 'traditional' when it had such a short period of time as the standard way of doing things with git. Git was created in 2005, and Github was created in 2008. So we had 3 years of email-driven git and 17 years of Github style development.
- PhilipRoman 2y ago
  Patches were being mailed long before that, since they work perfectly fine without Git.

bjackman 2y ago

It doesn't work smoothly for Linux kernel folks. It's a huge pain in the arse to review code. Some subprojects have CI but mostly it's too much work to set it up. You never know if the code that gets merged is truly what got reviewed. Half the time if you wanna test out someone's patches you have to spend 20 minutes trying to figure out what base commit they even apply to. Old fashioned mail clients are huge pain to deal with (and mail servers? Fuck). Raw text with no concept of "review thread resolved" wastes loads of review energy manually tracking what feedback has or hasn't been addressed. Comparing old and new versions of a patchset (equivalent of a pull request) requires manually searching your mailbox for the different versions, manually applying them to your local repo (hopefully you can find the base commit the old version applies to, which by now might not even exist any more if it's an unstable maintainer branch) and then manually running git-range-diff. As someone who works with an git-send-email workflow every day, I can tell you, it sucks. Email is not a good substrate for development. If I were Linus I would be pestering the Linux Foundation to set up a bunch of managed Gerrit instances or something.

imiric 2y ago
Don't they have tooling to help with these issues? Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. This won't align with everyone's preferences, of course, but I can't imagine someone like Linus not being happy with it.
- JoshTriplett 2y ago
  > Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. No, it really, really wouldn't. The Linux workflow is optimized for the preferences of (a subset of) maintainers, notably Linus; it is not optimized for contributors.
karel-3d 2y ago
The other guy got downvoted, but... isn't there really some tooling to help with this? Some standardized way of actually sending/reviewing the e-mails? sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...? One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! But I never had to actually use it.
- bjackman 2y ago
  No there are no standardised tools. There is Patchwork which can help with managing the review workload and can also provide some CI feedback, some subsystems use that with some succcess, other's don't. It's not really something an individual can adopt so if you're working in an area that doesn't use it you're out of luck. There is also Patchew which I've never tried. But overall everyone just has their own individual pile of shell scrips and mail client macros.
  - imiric 2y ago
    > No there are no standardised tools. Why would you expect there to be a standardised set of tools used by the largest distributed project in the world? Do you think that this would be possible to enforce globally in a way that makes everyone happier to contribute? You mentioned two tools that are used by some subsystems. b4[1] is another one, and more are listed here[2]. So there _is_ tooling around it that works for many people. It's just not your preferred choice of tooling, which is... fine. The fact that email is the lowest common denominator seems like a good thing to me. It allows everyone to use their tools of choice. As long as you can send and receive email, you can contribute. How you decide to integrate that into your development process is up to you. If you can't be bothered to setup a workflow from scratch, then you can adopt someone else's. I'd much rather have this choice, than be forced to use Gerrit or GitHub or whatever else. [1]: https://b4.docs.kernel.org/ https://b4.docs.kernel.org/ [2]: https://www.kernel.org/doc/html/v6.14-rc4/dev-tools/index.html https://www.kernel.org/doc/html/v6.14-rc4/dev-tools/index.ht...

sneak 2y ago

Email, like nntp and gopher, lost to the web. People won’t use it if it ain’t on the web. If you force them to use it anyway, very few people will use it. DdV’s advocacy stems from the fact that he is a lone-wolf dev, building tooling for other lone-wolf devs. The social and collaborative features sucking is a feature, not a bug. It falls flat on its face for larger projects and communities.

bigstrat2003 2y ago
> If you force them to use it anyway, very few people will use it. And that's perfectly fine. Not all things are for all people, and nor should they even try to be.
TylerE 2y ago
See, I don't think it has much to do with not being on "the web" and everything to do with federated services actually being a terrible fit for most users most of the time, and not worth the headaches (e.g. spam, netsplits, missing posts...)
specialist 2y ago
Noob questions: PRs are public and email patches are receiver's inbox only, right? When I'm assessing the merit of any given project, I'd want see if there's a backlog of PRs, right? Do projects using email-patch workflows set up listservs for receiving patches?
- MaxBarraclough 2y ago
  > PRs are public and email patches are receiver's inbox only, right? Not necessarily. For a 'lone wolf' project that might be the case, but some projects have public mailing-list archives, e.g. https://lists.gnu.org/archive/html/lightning/ https://lists.gnu.org/archive/html/lightning/ I think it would be necessary to do some manual copy+pasting, or else use custom scripts/tooling, to turn such mailing-list archive pages into patch files (for git apply) or mbox files (for git am).

cortesoft 2y ago

I think it is funny to think of the email-driven git workflow as 'traditional' when it had such a short period of time as the standard way of doing things with git. Git was created in 2005, and Github was created in 2008. So we had 3 years of email-driven git and 17 years of Github style development.

PhilipRoman 2y ago
Patches were being mailed long before that, since they work perfectly fine without Git.