I've been reminding myself aka procrastinating to self-host my repos for years until reading this post and spent a few minutes realizing just out how easily I could be interacting with my VPS' git service instead of github. obviously there's a long way to go but it's going to be a winning investment in terms of learnings and data ownership
Git without a forge
101–110 of 164 posts
Re: Git without a forge
#102I 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.
There are so many private hosting options for forges at this point that I don't buy the Github excuse anymore. Anyone who actually cares about decentralization can set up a Gitea/Gitlab server (or one of their forks) or use one of the many public alternative code forges. It's also quite common for projects to have read-only copies of their code on Github, where people can easily find them, with links to their real upstream in the README.
These days, Git forges left and right are even working on decentralizing things like issues and comments, something Git doesn't track or care about.
People flock to Github because it's free and easy. Very few people care about the peer-to-peer internet and decentralization that Git was built for.
Re: Git without a forge
#103> How do you send your patch to the maintainer? You send the author an email.
I understand the article thinks of occasional contributors outside of the project. For developers of your team (if any), I guess you could grant them SSH access to push, with git hooks enforcing your workflow (prevent direct commits to main, feature-* branches...).
Re: Git without a forge
#104> Sometimes people just can’t work out how to send me patches at all.
This could actually be useful for "open source but not open contribution" situations. It avoids the thing where people seeing that nice easy pull request button as somehow giving them the right to expect their contribution to be accepted.
"If you don't want contributors, why is it on [insert-forge-here] in the first place?" is a question I've seen asked in discussions about such things. Some people get personally insulted when their pull doesn't happen, even though the project states clearly ahead of time that this is how things are. Heck, some seem to be offended in advance that some hypothetical patch they might produce in future would be rejected.
Re: Git without a forge
#105This 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…
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! But I never had to actually use it.
Re: Git without a forge
#106Earlier 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…
Umm, why does a spammer bother with getting a Gitlab account in the first place?
Because it's $0 access to eyeballs.
Re: Git without a forge
#107> Sometimes people just can’t work out how to send me patches at all. This could actually be useful for "open source but not open contribution" situations. It avoids the thing where people seeing that nice easy pull request button as somehow giving them the right to expect their contribution to be accepted. "If you don't want contributors, why is it on [insert-forge-here] in the first place?" is a question I've seen…
This is basically what I do. Gitea instance with closed registration. So far I did get three different people sending me emails with patches/contributions and all the interactions were quite nice. Of course the stuff I am doing is not well known and I do not advertise it anywhere, which is its own moat I'd say.
Re: Git without a forge
#108The 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…
> ultimately just putting obstacles in front of other coders who might like to contribute
Saying it is just that after reading the full text seems rather reductive and unfair.
That is certainly a likely side effect, of course. It may even be a desirable one, avoiding, or at least reducing, several classes of time wasting contributions (like the glut of single typo fixing pull requests that resulted from an ill-conceived contribution based competition a while back), especially for "open source but not open contribution" projects.
Some projects are not wanting to optimise for the number of contributors above other considerations.
Re: Git without a forge
#109The 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…
People who can't grok email aren't making useful changes to PuTTY
Re: Git without a forge
#110Earlier quoted context omitted.
The biggest workflow differences I've noticed: - The repo normally lives outside of the worktree, so remembering to 'fossil new foo.fossil && mkdir foo && cd foo && fossil open ../foo.fossil' took some getting used to. Easy enough to throw into some 'fossil-bootstrap' script in my ~/.local/bin to never have to remember again. - For published repos, I've gotten in the habit of creating them directly on my webserver an…
> - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. That'd be a deal breaker for me. Git's s…
Not to mention this is kinda yet another hidden local version :)
I have a habbit to do git add -u when stuff I work on is in good state and I am about to try something more risky. I just stage the stuff, and keep hacking. If I fuck it up.. I can git checkout files or everything up to a stage.