Git without a forge • Hacker News Board

Re: Git without a forge

#31

Post by imiric » Thu, Mar 06, 2025, 12:33 AM UTC

bjackman wrote: post #9

MaxBarraclough wrote: post #4

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…

Don't they have tooling to help with these issues? Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. This won't align with everyone's preferences, of course, but I can't imagine someone like Linus not being happy with it.

Re: Git without a forge

#32

Post by JamesLeonis » Thu, Mar 06, 2025, 12:35 AM UTC

wahern wrote: post #17

> People can ‘git clone’ my code, and there’s a web-based browsing interface (the basic gitweb) for looking around without having to clone it at all. I host my own public Git repositories, but statically--read-only, no HTML views. I don't want to run any specialized server-side code, whether dynamic or preprocessed, as that's a security vector and system administration maintenance headache I don't want to deal with.…

I like this idea quite a bit. It's lightweight and read-only, which makes it far easier to host. I'm in the process of publishing some of my own repositories so I'm going to give this a try.

Re: Git without a forge

#33

Post by andyferris » Thu, Mar 06, 2025, 12:35 AM UTC

zem wrote: post #23

LadyCailin wrote: post #22

Earlier quoted context omitted.

You need to create an email account, and you’ll be doing that through a big email provider, if you want your emails to get delivered anywhere.

yes, but people have an email account already. if they could use that to interact with my git forge that would be ideal.

These days most every website has "log in with Google", "log in with Apple", "log in with Microsoft", etc which sort-of addresses the issue (ironically to this comment, "log in with GitHub" is also pretty common).

A more generic federated identity system that everyone could use/operate would of course be 1000% better. But slightly orthogonal to forge/no forge.

Re: Git without a forge

#34

Post by sneak » Thu, Mar 06, 2025, 12:36 AM UTC

johannes1234321 wrote: post #19

wahern wrote: post #17

> People can ‘git clone’ my code, and there’s a web-based browsing interface (the basic gitweb) for looking around without having to clone it at all. I host my own public Git repositories, but statically--read-only, no HTML views. I don't want to run any specialized server-side code, whether dynamic or preprocessed, as that's a security vector and system administration maintenance headache I don't want to deal with.…

I haven't looked into mich details of gibt's packing, but for a big repo you probably don't want a client to download it all nor do a huge amount of http range requests for being able to show the summary page. You think that would work well or would this need at least some caching layer?

You could write a static site generator to generate a website from the repo, so you’re still just serving static files.

Re: Git without a forge

#35

Post by ajross » Thu, Mar 06, 2025, 12:36 AM UTC

The security analysis in this piece is awful. Basically, author uses git because they don't trust "forges", then proceeds to discuss how a direct attack against the repository history is very hard but "not impossible"[1], while failing to recognize that the by-far-most-robust protection against such an attack is to push it to MORE repositories and MORE clones hosted by MORE entities and not keeping it secret on... your own piece of random hardware you probably got from Amazon.

The rest of it is reasonable advice as far as it goes. Learn how to replicate patches between raw repositories as a good practice, as you'll want to be able to do that anyway. Don't lean too hard on the GitHub abstraction of a "Pull Request" as that won't match what kernel people want, etc...

[1] Technically true, but in practice a ridiculous whopper.

Re: Git without a forge

#36

Post by sneak » Thu, Mar 06, 2025, 12:36 AM UTC

aard wrote: post #13

I very much support this sentiment! If we want a decentralized internet, we need to stop relying on large companies to manage everything for us. Git was designed to be a p2p system, but we very quickly centralized it with forges like Github. It is very discouraging. Most of the internet is like this now--managed by a handful of very powerful organizations. There is no end to the problems this will cause.

Gitea is a foss clone of GitHub that is implementing federation features. It’s absolutely excellent.

Re: Git without a forge

#37

Post by imiric » Thu, Mar 06, 2025, 12:38 AM UTC

adastra22 wrote: post #8

The way he prefers patches to him being sent (git repo URL + branch name) is basically what a forge does. Why make it more complicated for your users?

What's complicated about sending an email with the repo URL? The author concedes that just because they don't use a forge, it doesn't mean the contributors shouldn't.

Re: Git without a forge

#38

Post by sneak » Thu, Mar 06, 2025, 12:38 AM UTC

MaxBarraclough wrote: post #4

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…

Email, like nntp and gopher, lost to the web.

People won’t use it if it ain’t on the web.

If you force them to use it anyway, very few people will use it.

DdV’s advocacy stems from the fact that he is a lone-wolf dev, building tooling for other lone-wolf devs. The social and collaborative features sucking is a feature, not a bug.

It falls flat on its face for larger projects and communities.

Re: Git without a forge

#39

Post by bigstrat2003 » Thu, Mar 06, 2025, 12:38 AM UTC

adastra22 wrote: post #8

The way he prefers patches to him being sent (git repo URL + branch name) is basically what a forge does. Why make it more complicated for your users?

Why should it matter what potential contributors might want the workflow to be, unless his goal is to maximize contributors? There's nothing wrong with prioritizing your own tools desires, as long as you accept that it might limit how many people want to get involved.

Re: Git without a forge

#40

Post by JoshTriplett » Thu, Mar 06, 2025, 12:38 AM UTC

imiric wrote: post #31

bjackman wrote: 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…

Don't they have tooling to help with these issues? Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. This won't align with everyone's preferences, of course, but I can't imagine someone like Linus not being happy with it.

> Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors.

No, it really, really wouldn't. The Linux workflow is optimized for the preferences of (a subset of) maintainers, notably Linus; it is not optimized for contributors.