[ddevault]

>inline comments/reviews

>CI/CD integration

>merging from web interface

All of this is possible and planned for or already working on SourceHut. Remember, SourceHut is an alpha - don't write it off just yet because it's not entirely complete.

>Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete

I intend to follow-up with git-am.io at some point, for what it's worth. And I disagree that it's incomplete: it just encourages a workflow which doesn't use In-Reply-To. It covers follow-up patches without it.

>you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly

My response to this is (1) you can use multiple email clients for different reasons, you don't need to give up your current one; and (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am.

>Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table

Popular, yes. Superior, definitely not. But leaving that aside: I am okay with leaving potential users on the table. I'm not maximizing the possible userbase of SourceHut. I'm building a platform that embodies my development principles, for people who find those principles worthwhile.

[oefrha]

Good to hear all the planned features in this reply and https://news.ycombinator.com/item?id=23041522. One small clarification: re: inline comments/reviews, what I had in mind was all reviews aggregated on a single page, not scattered and obsoleted by each patch version, which means comments are basically lost if not immediately addressed.

Anyway, it seems to me that once you have all these planned features, the workflow would inch towards the Phabricator workflow, and to a lesser extent the GitHub workflow. The only major differentiator would be that you use emails to send in patches instead of using a branch. The actual code review activity would center around the web interface instead of the mailing list. That would mean (if my interpretations are correct) we disagree to a much smaller extent than I thought, but that would also mean your workflow is actually pretty different from “how git was designed to be used”, which I interpret as the mailing list-centric workflow of lkml (as I understand it; I’m not involved) and other old school projects I have participated in.

Re mail clients:

> (1) you can use multiple email clients for different reasons, you don't need to give up your current one;

It’s possible, but not pleasant. Each client needs to be configured so that mail intended for the other doesn’t clutter it up (not only inbox, but also search, archive, etc.). Usually people already use two or more mail clients to begin with (pc, mobile), so, more configurations.

> (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am.

Yeah I’m aware of this, but this just brings back the point that you’re using emails but then not really using emails...

[ddevault]

>Yeah I’m aware of this, but this just brings back the point that you’re using emails but then not really using emails...

_I_ like using emails. But the point of tools like that are so that people who don't like using emails can use other tools instead, and seamlessly collaborate with people who prefer to use emails.