Posted by ColinWright 7 days ago
But private stuff runs on my own servers.
In 2025 it's mostly maintenance free once the setup is running: Debian will be updated fully automated using unattended-update and the hosted application when there's the need to do one manually. Backups automatically every night using Proxmox and its little brother Proxmox Backup Server. Even with valid certificates using DNS-Auth from Lets Encrypt.
I don't even need to rent a server for that. Everything runs on my router (openWRT is amazing)
Let me repeat this again. We didn't centralize git when we started using github/gitlab etc. We centralized discoverability and reach of projects.
So far, everything else can be decentralized - issue tracking, pull requests, project planning, ci, release management and more. But we still don't have a solution to search projects on potentially thousands of servers, including self-hosted ones.
We do.
https://mvnrepository.com/repos/central
https://www.debian.org/distrib/packages#search_packages
https://elpa.gnu.org/packages/
And many others.
And we still have forums like this one and Reddit where people can just announce their project. Github is more of a bad code refuge than a high signal project discovery.
As an example, I had to reverse engineer some kinda obscure piece of hardware and after getting everything I needed for my project, I put everything on github in case it was useful to anyone. A few months later, someone was in a similar situation and built on top of my work. Neither of us made a "package" or even "a piece of software", just some badly written scripts and a scattered notes. But it was still useful to publish somewhere where others can find it, especially a place with very good SEO and code-optimized search.
You mean like Google? I can’t imagine ever searching just GitHub for software… I use a search engine and it’ll point me to GitHub or Gitlab or whatever frontend the software is published on.
I also find GitHub’s intra-project search to be so horrible that’s it’s quicker in the long run to just clone the project to my local machine and git grep there. And at least my local git doesn’t inexplicably choose to hide a few relevant results from me the way GitHub constantly does.
That sounds hardly like an alternative to what's possible with Github now. The only alternative that came anywhere close to that ideal was freshmeat - and even that didn't achieve the full potential. Check this discussion alone to see how many talk about 'network effects' or 'discoverability'.
And most software have an actual websites or is present in some distribution. I don’t care that much for weekend projects.
We aren't talking about your preferences alone here, are we? The case that the parent commenter mentioned is exactly what I was talking about too. What if I want a solution? What if I'm looking for algorithms or examples? What if I want to find a group of projects that's tackling a certain problem? How are my needs invalid? Are the projects that don't have such elaborate setups, polish or completion unworthy of discovery and help? You're essentially dismissing requirements that drive others to large platforms.
Why do you need a search index on your self hosted git server? Doesn’t Kagi solve that?
The search index doesn't have to be on your server, does it? What if there is an external (perhaps distributed/replicated) index that you could submit the relevant information to? Or if an external crawler could collect it on your behalf? (some sort of verification will also be needed.)
There are two reasons why such a dedicated index is useful. The first is that the general index is too full of noise. That's why people search projects directly on Github. The second problem is that the generic crawlers aren't very good at extracting relevant structured information from source projects, especially the information that the project owner wants to advertise. For example the readme, contribution guidelines, project status, installation and usage information, language(s), license(s), CoC, issue tracker location, bug and security reporting information, keywords, project type, etc. Github and sourcegraph allow you to do precise searches based on those. Try using a regular search engine to locate an obscure project that you already know about.
well, no. For my work, my favorite tooling is the one that:
- Allows 1-command checkout of proposed change
- Allows two-way discussion, with ability to comment either on specific lines of the patch, or on the overall system, and with ability to mark each comment "resolved" or not.
- Has some sort of dashboards that shows what needs to be done
I can use lowest common denominator - the email messages - but it is really lacking & awkward. Even basic merge request / pull request interface are much nicer.
As far as checkout, doing it with an emailed patch is one command, actually.
There is a native git request-pull command [1] that generates a summary of pending changes to pull into an upstream project, but it doesn’t enjoy support for all the features offered by GitHub pull requests or GitLab merge requests.
Initiatives like ForgeFed are trying to define a more neutral way to share this information, but I don't think there's any estimate date for when there'll be an actual implementation of it. If that ever happens, it'd be possible to get vendor-neutral tooling for that kind of collaboration.
Why are people so keen on having that network graph of forks? It's not necessary for collaboration. Status symbol?
If I want to fork your code and contribute back, that means I need to be on the same system as you.
There's a bunch of Gnome projects which require me to sign up to their specific git hosting service before I can contribute.
On most git servers, I have to fork in order to send a PR, which often means I have to create a fork on their system - which means I need to set up something to replicate it to my local machine.
It's all friction.
I'd love to see a project on (for example) GitHub and then clone it to my GitLab, work on it there, and send a PR from GL to GH.
You really don't. You just clone, code, commit, and send a patch (which is just one or more text files). That's it. You may just code and do a diff, if it's a simple fix.
The project may have a more complex policy to accept contributions. But a Fork and a PR is not a requirement.
How do I submit the patch to the repo on GitHub / GitLab / CodeBerg / whatever?
Presumably I need to hunt down the maintainer's email?
Have people forgotten that email exists?
Given that Git GUIs just invoke Git, I don’t have a lot of faith in it.
Can easily apply minor changes, just sharing it over slack.
Do you not see how much easier something like GH is?
GitHub seems easier because you are used to its workflow — which isn’t always devoid of arcanum either.
local$ git push
upstream$ git fetch && git merge
local$ git format-patch
local: open file picker for attachments.
upstream: save as ...
upstream$ git am
I don't know if you've ever used GitHub, GitLab, or CodeBerg - but PRs just appear in a list there. I don't need to do any work. Very handy especially if they're big changes.
I can also leave comments on specific bits of code, rather than emailing someone.
It's a joke, not a manifesto in a joke suit.
Since then there seems to be an uptick in blog posts that seem to have less content talking about the same things.
I guess I just talk into a void.
I sort of punted on receiving patches and merge requests because most of the projects I'm distributing in this way aren't really open source, but "published source" and there's a small community of people who use them. The people who use the public, read-only repos know how to generate patches and distribute them via email or (in one case) uploading them to an S3 bucket.
Anyway... your mileage may vary, but it's worked reasonably well for a small community. Not sure I would recommend it for a huge open source project.
Wouldn't 2. make transitioning them into 1. "impossible"?