Where do I see all patches neatly organized in threads, ready to be open as a timeline feed? Anything that involves custom filters or scripting an e-mail client is not easier nor more efficient than a web UI made for purpose.
How do I make a minor adjustment to a patch as a response to feedback without resending the whole thing? Anything more complicated than git commit && git push to my remote clone is not easier nor more efficient than the status quo.
These are just two off the top of my head. PRs as a code contribution approach can be improved upon, but mailing lists are not better at all for small projects and are only situationally better for bigger ones.
>Where do I see all patches neatly organized in threads, ready to be open as a timeline feed? Anything that involves custom filters or scripting an e-mail client is not easier nor more efficient than a web UI made for purpose.
>How do I make a minor adjustment to a patch as a response to feedback without resending the whole thing? Anything more complicated than git commit && git push to my remote clone is not easier nor more efficient than the status quo.
git commit && git push also re-sends the entire thing, assuming you rebased, and you should very definitely be rebasing.
That's a multi-purpose mailing list, where I had to read for a couple of minutes to assume belongs to the whole project sr.ht instead of a specific repo (I trusted your response to mean this was an actual 1:1 replacement and that I missed it), and I had to go into one of the patches and find a link to an issue in the tracker, and from there I had to go to the main page of that issue's project, and from there I see there's an ad-hoc association between the tracker and the actual repo by a link in the description which I assume you added because you noticed that it's useful to associate issue trackers and repos. And that's just for finding one of the repos that mailing list covers.
In the end, I still have to come up with custom filters to use to get only the patch requests for the specific repo I'm interested in, and assume everybody follows every single non-obvious instruction to the letter to make it all work.
The whole experience feels like a grabbing a bunch of general purpose tools and trying to get them to work for the project's purpose as well as possible, because there is no solution that solves the problem in obvious ways that doesn't require learning and carefully following a bunch of ceremony without failure. Except in this case, there are such solutions, and I'd have to be a sadist to try to get coworkers to learn and follow every single convention to the letter when they have problems just working well with git in the first place.
> git commit && git push also re-sends the entire thing
Which is not what I wanted, since even half-arsed PR implementations like Bitbucket's (let alone better ones like GitLab's) support dealing with direct feedback and changes that respond to them in a single PR.
> assuming you rebased, and you should very definitely be rebasing.
I do, when working on feature branchs. But that's another nonintuitive thing to get people to unlearn and relearn. Which of course, also includes git send-email.
I agree that it should be easier to find related resources, like the git repo a patch applies to. This is one of the issues prioritized during the alpha, and I'll ask for your patience and understanding that it doesn't represent an unfixable flaw - stuff like this is why we still have the alpha designation.
You can already filter by project, though. Here are all the git.sr.ht patches:
The feature is hinted at in the placeholder text on the search box.
>support dealing with direct feedback and changes that respond to them in a single PR.
Linking multiple versions of a patch together into one cohesive patchset is another thing which is possible in theory and prioritized for the alpha.
>I do, when working on feature branchs. But that's another nonintuitive thing to get people to unlearn and relearn. Which of course, also includes git send-email.
Well, for what little it's worth, you've convinced me to give sourcehut a try for a personal project where any of these shortcomings should not pose a problem.
You leave me thinking you actually give a shit about not leaving the average person behind and that ease of use is a priority. So if you can eventually couple the simplicity and performance you already have with slight changes to make the UI at least as obvious as GitHub to both programmers and students, then that's a winner. Just subscribed in hopes to seeing that happen.
How do I make a minor adjustment to a patch as a response to feedback without resending the whole thing? Anything more complicated than git commit && git push to my remote clone is not easier nor more efficient than the status quo.
These are just two off the top of my head. PRs as a code contribution approach can be improved upon, but mailing lists are not better at all for small projects and are only situationally better for bigger ones.