[thayne]

> There are no pull requests or merge requests. We use email, which is how Git was designed to be used.

I get that some people really like mailing lists, and I am aware of the shortcomings of the pull/merge request model. But I've never really contributed to a project that used mailing lists, and there are some problems I see with mailing list. Perhaps it's just my lack of familiarity with the workflow, but these are some advantages I think the github-style flow has:

- Ability to subscribe to individual pull requests. Many mailing lists are very high volume, and afaik, it isn't possible to subscribe to individual threads. Yes I could subscribe to the list and set up filters, but that is more difficult than subscribing to individual pull requests in github, and getting the filters right could be tricky.

- Ability to search by tags/labels

- Automatic linking between related issues and pull requests (with backreferences)

- The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list.

- Highlighting changes in the diff (source hut actually does this)

I'd be curious to know if proponents of the mailing list flow have anything to accomplish functionality similar to these. Or if there are any tools or tricks they use to make dealing with patch requests in email easier.

[emersion]

Many of these features can be implemented in lists.sr.ht.

lists.sr.ht already has support for threads and diff highlighting. Example thread: https://lists.sr.ht/~emersion/public-inbox/patches/7077

[ddevault]

Quick drive-by response:

>Ability to subscribe to individual pull requests

>Automatic linking between related issues and pull requests (with backreferences)

Both are planned

>The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list.

Not planned, but you can pretty trivially do this yourself. Just git checkout -b test-branch before applying the commits locally.

>Ability to search by tags/labels

Already there, kind of. You can search by the patch prefix, which is generally used to indicate the subproject. This is also supported outright on tickets, for which it's arguably a lot more useful.

[thayne]

> Just git checkout -b test-branch before applying the commits locally.

I guess that works, but it is a few more steps than clicking on a link. And if you are actively working on the project, it means you have to either switch branches or make a new workspace.

[fluffything]

TBH it sounds to me that you just need a better email client ?

Like... that's the program that handles everything that you mentioned.

[oefrha]

The best solution to email filtering is not receiving irrelevant emails in the first place. It’s always funny seeing people bending over backwards to justify terrible inconveniences they’re merely used to.

Plus, an email program that handles automatic cross referencing of tickets and commits? Where can I find that “better email client”?

[emersion]

aerc [1] supports arbitrary content filters (programs invoked when showing a message body). These are used for quote and diff highlighting. It would be nice to write a filter that auto-links tickets and commits depending on the List-Id.

[1]: https://aerc-mail.org/

[oefrha]

Automatic cross referencing is more than linkifying ticket ids and commit hashes. Issues, PRs and commits elsewhere that reference an issue/PR show up automatically on its page (think pingbacks in blogging), which apparently doesn’t fit into the mailing list model at all.

Edit: Forgot to mention, even

> It would be nice to write a filter that auto-links tickets and commits depending on the List-Id.

is not possible with sr.ht, due to non-1-1 relationship between mailing list and repository/tracker.

[pcr910303]

Well, an email client isn't a tool just for developing - it's a generic tool that has a lot of use cases. I don't think one should sacrifice features to get diff highlights or filtering PRs, nor should a generic email client try to implement out-of-the-box SourceHut filtering functionality.

Yes, one can use specific filters to accomplish subscribing to a particular PR, but that's complex, and when I'm using a generic email client I can't think of how it can not be complex.

[ignaloidas]

Nothing is stopping you from using more than one email client.

[thayne]

then you would need to configure filters across multiple email clients, which only makes the filter problem worse.

[mrmanner]

I use two, with very different filters. Since I use them for different things there’s not much overlap between the configurations. The total volume of conf is probably larger than if I’d used one client only, but the user experience is also a lot better (for me) since I can use the best tool in more cases.

[thayne]

Sure. What is that better email client? I don't mean to imply there isn't one, I'm genuinely curious what you email client you think has these features.