it's been hard being someone who's not a fan of the github monopoly and having to pick between gitlab (please don't), codeberg (they do a good job at copying github but I think we can do better) and sourcehut (super fast and efficient but they want you to use email to collaborate)

I just came across the idea of "patch requests": https://pr.pico.sh/

the idea is that instead of attaching your patch to an email, you ssh it to a service that tracks patches submitted; review on the patches is just done by submitting follow-up patches that put comments into the code; successive fixes that address the reviewer's issues delete the comments and then it's ready to go; you run a single ssh command to get a patch you can pipe directly to git am

when a patch is pushed it updates an RSS file you point your HTTP server at

no account needed, no client software to install; everything is spare and minimal but smooth

there's a demo video: https://www.youtube.com/watch?v=d28Dih-BBUw

I'm looking forward to trying it out; apparently it's still a fairly new project (first commit in March) but I think it has the potential to be huge by picking just the right slice of the problem to solve

@technomancy I am so down with this workflow. Holy shit. How beautifully elegant. It even solves for one of my most common PR/MR comments I leave: "can you transfer a summarized version of this conversation into a comment in the source?"

This is genius in that "damn, I wish I had thought of this years ago" way. Gonna have to try, thanks for sharing.

@klardotsh yeah one of my first thoughts was I wish I had come up with this, it's so simple but powerful

@klardotsh @technomancy this is just Gerrit (edit: after inspection, i think i am qualified to say "Gerrit but with unnecessary manual steps") ;p

@leftpaddotpy @technomancy FWIW I have long thought Gerrit is a pretty good idea in concept, though I haven't actively used it. At work we have an instance, but it's being phased out. I don't even know if my login works.

@klardotsh @technomancy I've been actively using it at https://gerrit.lix.systems and it's definitely the odd one out as far as being a project using non PR workflows but I've really enjoyed it

@technomancy oh my god the "hollup SSH keys is a Decentralized and Secure ID we can use for ethical PRs" is the missing key insight

I'd probably use pushes instead of patches (familiarity, unfortunately, is important. also, supports the "each commit is a checkpoint" model), but this is a really nice idea

@Parnikkapore yeah, the one thing I was a little unclear about is "why isn't this just a special kind of git remote"

either it's because the implementation would be trickier or because they genuinely think that has user-facing downsides, I'd love to know which

@technomancy what's wrong with gitlab?

@ikt @technomancy wondering the same

@naught101 @ikt @technomancy me three.

@ggg @naught101 @ikt haha oh man, where do I start?

I've used gitlab for over a decade, early on it was clunky and slow but fine and basically the only viable gh alternative other than gitorious

around 5 years ago things got to the point where new bugs started popping up constantly; I'm not a super frequent gitlab user, but in the past 4 years, literally every time I logged in I would see at least one brand new bug that I had never seen before... every time

@ggg @naught101 @ikt it got to the point where I started wondering if they were adding bugs specifically to mess with me personally

I later found out this matched the timeline of their VC investors pushing to get some returns on their investment by going feature-wild so they could sell, sell, sell the latest hot thing (today it's AI, previously it was devops, to the point that I would repeatedly get banners popping up with increasing levels of desperation telling me how cool it would be to deploy my emacs config codebase using their brand new kubernetes integration)

@technomancy I'm not sure I understand yet why they prefer patches over branches, but I fully agree this is a much-appreciated fresh take! Looking forward to seeing where this goes and what other ideas it sparks!

@raboof @technomancy branches are a way to track work in progress. You don’t need them to submit or review a patch, but they can make it convenient.

For the demo they would have added extra steps.

@technomancy isn't this just Gerrit but with weirder UX

@leo does gerrit store the review contents in git? I hadn't heard that

but I think gerrit requires you to create an account, right? so it's a lot less streamlined

I’m not sure if I like or dislike this idea, but it is novel.

RE: https://hey.hagelb.org/@technomancy/statuses/01J2NAZEBENHZG872QA50PCB2P

@technomancy What's wrong with gitlab ?

@skizorutabaga I explained it here: https://hey.hagelb.org/@technomancy/statuses/01J2PC9Q8GHG21X1H0X1WMJK1R

@technomancy pretty interesting workflow

would be interesting to see how large teams fare with it

@jnpn luckily for me I've never been part of a large team =D

@technomancy @leo Might be interested in this:
https://github.com/google/git-appraise

@csepp

oooh, thanks

@technomancy @leo

@idlestate @csepp @leo looks neat, but I think storing the review comments in the files being reviewed feels better and removes the need for the submitter to install anything (step 1 of the instructions right now seems to be "install hundreds of megabytes of corper compiler toolchain" which will certainly turn a lot of people away)

makes me think maybe what I want is just a git server that accepts (non-force) pushes from anyone and gets wired into IRC/email/RSS notification systems

the contents of the reviews themselves can be treated like completely normal git commits on completely normal git branches; the only thing that needs to be novel is the public-write status and the notifications

@technomancy no but it's the same idea of submitting patches with standard CLI tools

@leo @technomancy no actually I'm almost certain it does store the review contents in Git

@Qyriad @technomancy "Gerrit metadata is also stored in Git, with the commits marking the historical state of metadata. Data is stored in the trees associated with the commits, typically using Git config file or JSON as the base format. For metadata, there are 3 types of data: changes, accounts and groups." oh huh nm then

@leo @technomancy we don't know where everything is but we know for certain that some parts of the code review even goes in the git-notes for that commit, which is about the only time we've ever seen the git-notes feature used

@Qyriad @leo yeah it's neat but this has made me realize I actually want the review comments inside the files being changed, not just somewhere in the repo metadata