Top
Best
New

Posted by ColinWright 7 days ago

Some thoughts on personal Git hosting(shkspr.mobi)
102 points | 93 commentspage 3
ghosty141 4 days ago|
gitweb + gitolite is all you need in my opinion for hosting private projects. I have had a wonderful experience with it since there are no complex databases, config files etc and it’s very light on resources
goku12 3 days ago||
There are two unresolved problems preventing us from effectively replacing github or similar centralized forges with a fully decentralized/self-hosted ecosystem. These are the factors that keep pushing people back onto those platforms.

Note: Please add any major issues that you consider as a blocker. And, apologies for repeating some points that I expressed in other comments. I wasn't planning to write a top level comment.

So, Problem 1: Discoverability and network effects. This is the main reason why people keep going back to the largest platforms. There is practically zero chance of being seen or helped on self-hosted or small platforms. And this isn't because of a missing technical innovation either. Those platform has the size and first-mover advantage. What we need is a single feature-rich search interface to query all those projects spread over the net. That would need an index. Unlike the interface, the index itself can be distributed or replicated to avoid centralization. It should be able to store structured information about projects, like instructions (readme, usage, contributor guidelines, license text, CoC, etc), license, language, pull-request interface, issue tracker location, bug/security reporting information, project type, ownership details, signing information, etc. This will allow rich searches like what's possible on github and sourcegraph.

Problem 2: Communication channel. The biggest problem hindering distributed git hosting is a way to do pull-requests, code reviews, discussions, etc. Even with something like gitea, you need an account on every instance where you want to contribute. The truth is that we already have a communication channel that allows such a collaboration - email. We already have working proofs of how it operates at LKML and sourcehut. However, people have a particular dislike towards emails for git collaboration. IMO, this is actually the fault of email clients that absolutely massacre the elegance of plaintext emails. There are some powerful tools that's used with LKML that most people will never discover because of their hatred towards email. Sadly, email is a lost opportunity that could have been a delight with sufficient attention on the clients.

I have given up trying to convince people to give it a try. Email is somehow a taboo in this generation. So what else? There are projects like radicle (stable, more about it later) and forgefed (activitypub, under development) that try to build such a channel. But you really don't need to create such a channel for git. Git can adapt to any current channel (eg: xmpp/movim, nntp) using its extension mechanisms. Email was probably just the default channel. You can do patch pushes (git format-patch) and pull requests (git request-pull) practically through any such channel. With a bit of attention on the UI/DX, you can avoid the mistakes of emails (like html) that made them harder to use for our purpose. Additionally, you'll also need to build other development tools (issue tracker, code review, discussions etc) around them. People got too fixated on the platform approach and missed the possibilities of protocols.

Radicle: Honestly, I don't know what to make of it. It's a very impressive effort and they seem to have solved some very difficult problems. But radicle also seems to have gone for a platfom based approach and it encompasses everything. They seem to have an integrated issue tracker, CI system etc. If its scope was restricted to just a p2p network for discovering and exchanging git objects and other arbitrary information, we could have built a wide ecosystem of development tools on top of it. Radicle also feels like a darkweb that exists on a different plane from the web, though web bridges exist. For example, you can't do a clone of a repo from the net, unless it's bridged somewhere. However, I reserve my final opinion is reserved until I have a proper insight. I may have some wrong assumptions here. Please let me know if I do.

edent 3 days ago|
It isn't that email is taboo. It is that it is effort.

I have to go to my email program. Download the patch. Upload it. And then, if I want some changes, have to copy-and-paste stuff into a reply. Then repeat.

That's more effort than clicking "review" on a hosted git service.

A theoretical future service could use email under the hood to send messages back-and-forth between instances. But that's just an implementation detail.

goku12 3 days ago||
That sounds like a UX/DX problem, doesn't it? You could have a tool that automatically deals with the tedious/repetitive parts of the workflow.
gitprolinux 4 days ago||
I simply use my own githosting product for my source code products at https://GitBusiness.com
worldsavior 4 days ago|
Why people self host a git site? If they're not an organization and are not looking for views, there aren't any reasons to self host.
cinericius 4 days ago||
They want to have control over where their code lives, and not have their code subject to the terms of the service of the platform they use.

For example, I might want to host my code privately on GitHub and not have Microsoft use it to train their LLMs. That doesn't seem to be possible:

https://github.com/orgs/community/discussions/135400

https://github.com/orgs/community/discussions/171080

packetlost 4 days ago|||
I self-host most of my personal git repos on a NAS. They're literally just `git init --bare` folders in `/srv/src` that I access over SSH. Requires essentially zero setup and maintenance and I don't have to be worried if my internet or some other provider dies.
quectophoton 4 days ago||
This also allows more freedom in the directory structure, instead of the `$USERNAME/$REPONAME` that is enforced by basically every hosted solution.
packetlost 4 days ago||
Yup, though you actually lose the ability to control access via groups in the URI this way (not that it matters, it's way more flexible to use Unix FS permissions)
bayindirh 4 days ago|||
I do some personal R&D and want to keep it under wraps until I'm ready to share it to the world. Keeping stuff on services you can depend is great for many things (I use SourceHut, btw.), but sometimes you want to have your code on-premises.

This is not the next billion dollar business, but I don't want to share the code until I write a couple of papers on it, and anchor the code's and idea's provenance correctly.

I had a softer stance on the issue, but since AI companies started to say "What's ours is ours, and what's yours is ours", I need to build thicker walls and deeper moats.

No, it won't be permissively licensed if I open source this.

panny 4 days ago|||
I would self host if I also wanted build actions, issues, wiki like Github/Gitea support. I believe the article is about this part. How do I collaborate with others without building a dependency on a tyrant? Gitea + Traefik + Keycloak + federated github login probably does the trick these days. It's been a while since I built a SDLC project.
snmx999 4 days ago||
I self-host a git site to keep my code private and to integrate an issue tracker. The maintenance effort is very low. I'm running Gitea on my local network Ubuntu server.