4 ms·

There are vast swaths of devs who are not aware people still use mailing lists, nor that git has first class support for applying patches from emails.

crdrost 3y ago
And that this is not just a minor niche use case, "the largest and oldest Git project that is, Linux, uses a mailing list and patch files to develop."
- bananapub 3y ago
  it is definitely not the oldest
  - JoshTriplett 3y ago
    In the sense that it was the first project to use git (has been using git the longest), not in the sense that it's the oldest project that switched to git.
  - smohare 3y ago
    [dead]
  - cesarb 3y ago
    > it is definitely not the oldest IIRC, the oldest was git itself (it self-hosted early on its development history); git, linux, and sparse are IIRC the three projects that have been using git the longest.
- forrestthewoods 3y ago
  TBH I definitely consider Linux a niche use case. It’s an outlier relative to 99.99% of projects.
  - bembo 3y ago
    How can Linux be a niche use case for git if git was made as a version control system for Linux?
    - forrestthewoods 3y ago
      Niche use cases are a great reason to make a bespoke tool! But that doesn’t make it not a niche use case. And it doesn’t mean that tool is optimal for the common use case.
- electroly 3y ago
  Note that Linux, today, is far from the largest Git project. Oldest, yes. Biggest, not even close. FAANG monorepos are vastly bigger with much higher commit rates. The Linux kernel is quaint, small, and moves glacially slow in comparison. Even if we consider only public open source codebases, Chromium's repo is bigger than Linux by any reasonable metric.
tiffanyg 3y ago
... apparently ... that's rather absurd ... perhaps I won't listen to this presentation when time might allow, for the moment. https://youtu.be/1Npo0cmp-VY https://youtu.be/1Npo0cmp-VY On second thought, let's not go to Camelot, tis a silly place.
PaulDavisThe1st 3y ago
We don't even do that. ardour.org self-hosts gitea, and that allows for PRs etc. We don't expose that to "the public", for now, just because github is familiar to more people. But we could.
- mcronce 3y ago
  I self-host Gitlab, which is pretty familiar to people, but I still mirror repos for which I'm hoping to get contributions to GitHub for the same reason
da39a3ee 3y ago
> git has first class support for applying patches from emails. You say that like it's a good thing.
da39a3ee 3y ago
No-one should be applying patches from emails. I know several people will react with certainty that I'm wrong, but email-patch-based flows are just used because the old-timers using them are very accustomed to it. It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify: in other words a patch doesn't exist in isolation. Git is great; I'm not saying everyone should use any particular Git-hosting or code review framework. But the fact that the inventor of Git continues to use email in one particular project with many expert and experienced contributors has more to do with their expertise and experience (aka age) than with the benefits of email. I mean look at the reality of these people's workflows: they're using things like Mutt and Gnus to read email locally and apply patches from local email. I get it, I've done it, I've even run a local dovecot for the purpose. It had it's time in technological history. That time isn't now. There are multiple open source projects that I would have contributed to were it not for the email-based flows (e.g. emacs).
- Sprocklem 3y ago
  I strongly disagree. I've recently contributed to a project that uses an email-based workflow, and find it considerably easier to use: after a surprisingly brief one-time setup, I can contribute patches using a single `git send-email` command from the same terminal that I make my commits, and can review and comment on patches from my email client of choice (thunderbird) – all without needing to create a new account. Applying patches is, admittedly, a little more awkward, but it can still be done in two or three steps from thunderbird (including invoking `git am`) and, I understand, some newer email clients can handle this much much better. > It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify: This is no longer a problem. `git send-email` (and `git format-patch`, if you prefer to call it directly) has for a while supported a `--base=auto` or the `format.useAutoBase` configuration option to attach the upstream commit ID to the patch. To my knowledge this is currently only to help the maintainer understand its context but there is ongoing discussion of ways to automatically use this information.
  - da39a3ee 3y ago
    How is that better than having shared access to a remote git repo and your collaborator sending you a commit sha and branch name? Note that I'm not suggesting you use any for-profit company's hosted git product.

crdrost 3y ago

And that this is not just a minor niche use case, "the largest and oldest Git project that is, Linux, uses a mailing list and patch files to develop."

bananapub 3y ago
it is definitely not the oldest
- JoshTriplett 3y ago
  In the sense that it was the first project to use git (has been using git the longest), not in the sense that it's the oldest project that switched to git.
- smohare 3y ago
  [dead]
- cesarb 3y ago
  > it is definitely not the oldest IIRC, the oldest was git itself (it self-hosted early on its development history); git, linux, and sparse are IIRC the three projects that have been using git the longest.
forrestthewoods 3y ago
TBH I definitely consider Linux a niche use case. It’s an outlier relative to 99.99% of projects.
- bembo 3y ago
  How can Linux be a niche use case for git if git was made as a version control system for Linux?
  - forrestthewoods 3y ago
    Niche use cases are a great reason to make a bespoke tool! But that doesn’t make it not a niche use case. And it doesn’t mean that tool is optimal for the common use case.
electroly 3y ago
Note that Linux, today, is far from the largest Git project. Oldest, yes. Biggest, not even close. FAANG monorepos are vastly bigger with much higher commit rates. The Linux kernel is quaint, small, and moves glacially slow in comparison. Even if we consider only public open source codebases, Chromium's repo is bigger than Linux by any reasonable metric.

tiffanyg 3y ago

... apparently ... that's rather absurd ... perhaps I won't listen to this presentation when time might allow, for the moment. https://youtu.be/1Npo0cmp-VY https://youtu.be/1Npo0cmp-VY On second thought, let's not go to Camelot, tis a silly place.

PaulDavisThe1st 3y ago

We don't even do that. ardour.org self-hosts gitea, and that allows for PRs etc. We don't expose that to "the public", for now, just because github is familiar to more people. But we could.

mcronce 3y ago
I self-host Gitlab, which is pretty familiar to people, but I still mirror repos for which I'm hoping to get contributions to GitHub for the same reason

da39a3ee 3y ago

> git has first class support for applying patches from emails. You say that like it's a good thing.

da39a3ee 3y ago

No-one should be applying patches from emails. I know several people will react with certainty that I'm wrong, but email-patch-based flows are just used because the old-timers using them are very accustomed to it. It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify: in other words a patch doesn't exist in isolation. Git is great; I'm not saying everyone should use any particular Git-hosting or code review framework. But the fact that the inventor of Git continues to use email in one particular project with many expert and experienced contributors has more to do with their expertise and experience (aka age) than with the benefits of email. I mean look at the reality of these people's workflows: they're using things like Mutt and Gnus to read email locally and apply patches from local email. I get it, I've done it, I've even run a local dovecot for the purpose. It had it's time in technological history. That time isn't now. There are multiple open source projects that I would have contributed to were it not for the email-based flows (e.g. emacs).

Sprocklem 3y ago
I strongly disagree. I've recently contributed to a project that uses an email-based workflow, and find it considerably easier to use: after a surprisingly brief one-time setup, I can contribute patches using a single `git send-email` command from the same terminal that I make my commits, and can review and comment on patches from my email client of choice (thunderbird) – all without needing to create a new account. Applying patches is, admittedly, a little more awkward, but it can still be done in two or three steps from thunderbird (including invoking `git am`) and, I understand, some newer email clients can handle this much much better. > It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify: This is no longer a problem. `git send-email` (and `git format-patch`, if you prefer to call it directly) has for a while supported a `--base=auto` or the `format.useAutoBase` configuration option to attach the upstream commit ID to the patch. To my knowledge this is currently only to help the maintainer understand its context but there is ongoing discussion of ways to automatically use this information.
- da39a3ee 3y ago
  How is that better than having shared access to a remote git repo and your collaborator sending you a commit sha and branch name? Note that I'm not suggesting you use any for-profit company's hosted git product.