Live data from Hacker News

Git without a forge

chiark.greenend.org.uk

111–120 of 164 posts

Re: Git without a forge

#111
post #9

Earlier quoted context omitted.

It doesn't work smoothly for Linux kernel folks. It's a huge pain in the arse to review code. Some subprojects have CI but mostly it's too much work to set it up. You never know if the code that gets merged is truly what got reviewed. Half the time if you wanna test out someone's patches you have to spend 20 minutes trying to figure out what base commit they even apply to. Old fashioned mail clients are huge pain to…

The other guy got downvoted, but... isn't there really some tooling to help with this? Some standardized way of actually sending/reviewing the e-mails? sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...? One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! B…

No there are no standardised tools.

There is Patchwork which can help with managing the review workload and can also provide some CI feedback, some subsystems use that with some succcess, other's don't. It's not really something an individual can adopt so if you're working in an area that doesn't use it you're out of luck.

There is also Patchew which I've never tried.

But overall everyone just has their own individual pile of shell scrips and mail client macros.

Re: Git without a forge

#112
I ran a ssh server for a while to store git repositories. We had some with secrets in and I didn't want them on github. I needed to provide read only access and read write access for only some of the repos. I ended up with a bash script that configure system users and groups and permissions to do the job. It's here:

https://github.com/artumi-richard/ssh-git-hosting

I stopped using it years ago. It had the additional advantage of no artificial limits (file sizes etc).

Re: Git without a forge

#113
post #75

Earlier quoted context omitted.

The only way to do it is disable registration and have people contact you to allow registration.

We do this in Arch Linux. It requires someone handling the registrations which isn't great either.

Seems like something LLMs should be good at. Take the new user info and ask it to vet the account or raise it to a human.

Re: Git without a forge

#114
> If you can’t find a button on a website to submit a patch, how do you send your patch to the maintainer? You send the author an email.

"Did you just tell me to go fuck myself?"

"I believe I did, Bob."

Re: Git without a forge

#115
> I get particularly annoyed when people demand I move to Github for this reason. “Everyone is on Github, get with the programme! Conform!” I’m actually less likely to do it because you said that. Ugh.

I 100% agree. When people say things like "You have to be on GitHub because that's where the community is" I don't know what to say. Who cares? Is it really that hard to log into (or not) a different Git server? Do we really want to encourage this idea of community anyway, at a scale larger than an individual project?

Re: Git without a forge

#116
post #82

The only thing I can ever think of while reading these things is: Why? What could possibly possess you to want to review and apply patches through email? The whole mentality is just utterly foreign to me.

the author explains his reasons in considerable detail in the article...

Re: Git without a forge

#117

> A particular thing I don’t like about git forge websites is the way they make you create an account. Exactly. I used to have a GitHub account but as soon as it got bought out by Microsoft, I was gone. I still refuse to create an account, even though there have been bugs I wanted to report or patches I wanted to contribute. Maybe some maintainers still have email addresses on their profile, many don't. Even if they…

I am curious -- what is your concern about creating an account? Is it security? Privacy? The need to keep track of it?

Re: Git without a forge

#118
post #67

Earlier quoted context omitted.

Forgejo (once federation is implemented) also fixes the main issue of forcing people to have an account at every forge.

It does solve that problem, but then creates a huge spam problem. Over at gitlab.xfce.org we are constantly fighting new spam accounts that get created daily. We've done all the recommended/paranoid things, like not allowing new accounts to fork or create repos until we manually give them permission (among other things), and we have a script that runs hourly to shut down suspicious accounts. But it's still nuts. If a…

> If anyone with an account on any other gitlab instance could automatically do things on our gitlab instance

I think the idea is the exact opposite, no? People wouldn't be able to do anything on your forge. They would only initiate actions on their own server and then send you notifications of PR requests to the ActivityPub inbox of your repository, and spammers would have no incentive to do this because nothing would end up in public view.

Re: Git without a forge

#119

Earlier quoted context omitted.

Sorry, did you have to use a Wide character? There is a Narrow version of it: ⟫ U+27EB MATHEMATICAL RIGHT DOUBLE ANGLE BRACKET.

Does it cause problems on mobile or something?

Well, no, I've just spent some time recently on wrangling narrow and wide characters in the terminal emulators (and fonts they use) and I guess I am now somewhat more sensitive to the suspiciously looking whitespace.

Do you know that, for instance, that the playing card symbols in the Unicode are narrow characters, the terminal emulators treat them so yet the fonts draw them as 1.5-cells wide which causes ugly and annoying overlaps?

Re: Git without a forge

#120
post #9

This reminds me of Drew DeVault's advocacy for the traditional email-driven git workflow. [0][1] (Drew is the creator of SourceHut, an email-oriented git forge.) I think his (Simon's) objection to git send-email emails could be addressed with better tooling, or better use of them. It's 'just' a matter of exporting the emails into a single mailbox file, right? (I'm not experienced with git's email-driven features.) It…

It doesn't work smoothly for Linux kernel folks. It's a huge pain in the arse to review code. Some subprojects have CI but mostly it's too much work to set it up. You never know if the code that gets merged is truly what got reviewed. Half the time if you wanna test out someone's patches you have to spend 20 minutes trying to figure out what base commit they even apply to. Old fashioned mail clients are huge pain to…

[flagged]
Post reply on HN