Live data from Hacker News

Git without a forge

chiark.greenend.org.uk

91–100 of 164 posts

Re: Git without a forge

#91

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…

The regular forges have just as many obstacles. You have to register an account, figure out whether the button you need is 'Pull Request' or 'Merge Request', and what the exact flow is.

The only reason things appeared simple in the past is because of GitHub's monopoly. As soon as you want to get rid of that, life gets more complicated. That is just another tradeoff you have to make.

Re: Git without a forge

#92
post #70

> Also, I might as well come out and say this: one reason I don’t want to use Github is because it’s the most popular place to host your code. It's the goth subculture of software development! Because it's popular, it must be eschewed. Geez.

You conveniently left out the justification for that statement: because the author believes monocultures are bad, and doesn't want to support them. I think that's entirely reasonable, and characterizing it as "goth subculture" is dishonest.

> monocultures are bad, and doesn't want to support them

is just

> it's popular, it must be eschewed.

after a chatgpt pass

Re: Git without a forge

#93

Earlier quoted context omitted.

I’d go with a combined approach. Static pages for every file on master, JS for everything else. This way master branch loads instantly, but other branches (with diff, blame etc) are also available. Hmmm, I might give it a go one day.

Would the js pages really take much longer to load than static? Fetching a few packfiles and hydrating a template should be very fast.

Probably. We’re looking at three roundtrips here: one to fetch the HTML, one for the JS, and at least one for the packfiles (and that’s if you can do that in parallel). If the latency is high, the result can be... not great. HTTP/2 should help with this a bit, but it’s better to not have this problem at all IMO.

Of course, there’s also the argument that if you’re self-hosting a repo, you’re more likely to care about users that have disabled JS (which is a good idea, tbh).

Re: Git without a forge

#94
post #38

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.

See, I don't think it has much to do with not being on "the web" and everything to do with federated services actually being a terrible fit for most users most of the time, and not worth the headaches (e.g. spam, netsplits, missing posts...)

Re: Git without a forge

#95
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.

Well, there's https://radicle.xyz/ but it doesn't seem too popular—that is, I've never seen a project that is hosted on it.

Re: Git without a forge

#96
post #12

as someone who finds the whole forge interface a massive improvement in git collaboration workflow I was fully prepared to find the author's arguments against a lightweight self hosted forge unconvincing. but the "need to create an account" is an extremely valid drawback, and one I do not have a good answer to.

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.

I am running my own email server for several years and most of the services on the internet are happily integrate with it. The only times I think I had some sort of the problem was small companies with incorrectly configured exchange that was refusing to deliver my messages.

Re: Git without a forge

#98
post #6

> Sometimes people just can’t work out how to send me patches at all. Yeah indeed. I have written but not submitted patches to a project (OpenSBI) because it made the submission process super complicated, requiring signing up to a mailing list, learning how to set up git send-email. I don't see how he can think creating a GitHub account (which almost everyone already has) is a big barrier when he freely admits his pr…

I submitted at least one patch to putty some time ago and it was such a nothingburger I don't even remember what it took. Somehow it neither baffled nor infuriated nor even annoyed me a little. All these complaints and critiques sound like so much baby crying over nothing to me.

Same with the account creation on normal git websites. You fill out three fields and click a link in your email, it's no more complex than git send-email.

I'm sure I can figure out the archaic git email system, how hard can it possibly be? Same with the git bundle thing, this is the first time I've read about it but it seems usable. I don't expect anyone I'll ever directly work with to know what the hell a bundle file is but if a project wants their git commits in that format, it shouldn't be that much of a problem. The biggest hurdle will probably be spam filters, but that's an email problem and not necessarily a git problem.

Or course the downside to all this funky command line stuff is that you're applying a filter on the people who will ever contribute code. Plenty of people don't want to figure out the git's many weird command line flows and communication options. Plenty of developers don't care enough to actually learn about git beyond push/pull/rebase/merge. If you're only interested in the turbo nerds who enjoy using the many tricks git has to offer, you'll probably filter out most contributors, but realistically how many contributors does hobby project on a personal git server ever attract in the first place.

Re: Git without a forge

#99
Interesting how author integrated devops side of his software. Main part why I am running whole GitLab suite for my own projects (like a mobile application for my home control) is to have automatic, build, test and deployment process.

I really disliked i.e. pushing new artifacts for fdroid repo. Build can be very long and I do not plan to look at the command line progress for 30 minutes to make sure that it is ready to be pushed to release.

I guess someone can automate this with some cron jobs or bash scripts, file watchers and etc. But moving it to new machine it so much trouble. With GL I can just make a backup and restore it on the other machine. With everything running in docker it is much easier to get the environment running.

Or at least for me.

Re: Git without a forge

#100

> Also, I might as well come out and say this: one reason I don’t want to use Github is because it’s the most popular place to host your code. It's the goth subculture of software development! Because it's popular, it must be eschewed. Geez.

Being popular makes something a high value target. I think it's quite reasonable to have a threat model which avoids such things.
Post reply on HN