Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git without a forge

chiark.greenend.org.uk

Post reply on HN
Print view View original

81–90 of 164 posts

Re: Git without a forge

#81

Post by duskwuff »

sneak wrote: post #36
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.

One thing which is particularly excellent about Gitea (and its fork, forgejo) is that it's quite lightweight for what it does. It's a single-process Go application with low memory requirements, and it can use a SQLite database (so you don't need a separate database server).

Re: Git without a forge

#82

Post by Aeolun »

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.

Re: Git without a forge

#83

Post by Svenstaro »

pabs3 wrote: post #75
kelnos wrote: post #67

Earlier quoted context omitted.

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…

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.

Re: Git without a forge

#84

Post by jarofgreen »

sneak wrote: post #34
johannes1234321 wrote: post #19

Earlier quoted context omitted.

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.

https://git.trevorbentley.com/itsy-gitsy/ (I don't use so not sure how good it is, just noting)

Re: Git without a forge

#85

Post by aitchnyu »

kelnos wrote: post #67
rglullis wrote: post #11

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…

Umm, why does a spammer bother with getting a Gitlab account in the first place?

Re: Git without a forge

#86

Post by PhilipRoman »

cortesoft wrote: post #80
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…

I think it is funny to think of the email-driven git workflow as 'traditional' when it had such a short period of time as the standard way of doing things with git. Git was created in 2005, and Github was created in 2008. So we had 3 years of email-driven git and 17 years of Github style development.

Patches were being mailed long before that, since they work perfectly fine without Git.

Re: Git without a forge

#87

Post by ackyshake »

> 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 do, I just don't get the motivation to email them.

People like to complain about email a lot, but I enjoy different mailing lists for open source software. You could have discussions with other users of that software or keep track of development by following the "-devel" list. All you needed is something you already had—email. Sadly, they're becoming less popular. Even python moved to discourse which—dun dun dun—requires an account. grumble grumble

I like SourceHut for many reasons—it's the fastest forge I've used, it's FOSS, doesn't try to copy the GitHub UI like every other Git forge these days. But by far the reason I love it is _because_ it doesn't require me creating an account to contribute. I think of it as gitweb, but nicer.

Re: Git without a forge

#89

Post by mellosouls »

The author is obviously entitled to whatever workflow he chooses to use, and he isn't proselytizing here, but by choosing to sidestep industry standards he is ultimately just putting obstacles in front of other coders who might like to contribute.

Unless you're really into git and email, it's just tiresome and a time sink having to work all this out.

Fwiw I've used putty in the past and appreciate his efforts, if not his obscurantist tendencies.

Re: Git without a forge

#90

Post by mauricioc »

LegionMammal978 wrote: post #29
rlpb wrote: post #25

> Multiple files to herd. When I get an email with five patch attachments, I have five files to copy around instead of one, with long awkward names. That’s not correct. You can write the email to an mbox file (your MUA lets you do that, right?) and then use `git am` to pull it all into git. > Why I don’t like it: because the patch series is split into multiple emails, they arrive in my inbox in a random order, and th…

Not everyone has a fancy client-side MUA that gives them trivial access to mbox files. E.g., a typical webmail service will make exporting mboxes into a whole process at best. (And on the sending side, have fun with the lack of git send-email integration. I've spent far more time than I'd like manually patching up References and In-Reply-To headers.) Of course, the classic response is "get a better MUA you luser", bu…

> Of course, the classic response is "get a better MUA you luser"

Git is distributed and allows you to work efficiently with poor connectivity, having full history available at any time, which is a big accessibility point for people with limited connectivity (and also helps people working while traveling, for example). If you do have any email client, you get all of this as well, plus arbitrarily powerful, low-latency filtering and searching. I recommend Greg KH's "Patches carved into stone tablets" talk [0].

Despite your "luser" strawman, people advocating for client-side MUAs mean well and have a point. Try replacing "webmail" by "Notepad" and "client-side MUA" by "emacs/vim" to see how your argument sounds. You probably spend a decent amount of time interacting with email, and the investment in setting up a fast, flexible and powerful environment (preferably reusing your text editor for composing messages) for doing so pays for itself soon.

[0] https://www.youtube.com/watch?v=L8OOzaqS37s

Post reply on HN