Moving away from GitHub also involves a cost: less visibility, harder to create new projects, harder to get people to report bugs (every site has their own login), or maintenance burden (fighting of spam), less features, paying for hosting. Is it worth it? Perhaps.
Self hosting or hosting in smaller communities has has benefits: knowledge is power (but it’s also an investment that you might not be prepared to make), social interaction (I fell better organizing with friends than leeching off venture capitalist money). And thus even less slick options like GNU Savannah are looking good. If all you need is git hosting and browsing code it will do fine. And my self hosting is just that: git + cgit + self-written ticket wiki.
I’m still confused by the quest for git federation. Git is federated. When I have a local git repository, it’s a complete repository. When I push changes I can pick any git repository that gives me access. So it’s all a question of permissions. Usually, my local work directory is not reachable from the Internet, so other people cannot pull from me directly. The solution is to have a special git user with no shell, every developer gets their public key added, and now they can use the SSH transport to connect with the git user and this git user has “bare” git repositories which for all intents and purposes are just “more git”. There is no separate server-to-server layer. The difference between my local clone of the repository and the bare repositories of this git user on my system are simple a question of connectivity and access.
I think this lack of a separate server-to-server layer confuses some people. What they are thinking of is a two-layered federation like Mastodon or Email. Git only has one layer. Every repo is a server. We just usually don’t give other people access to our local servers. But we could.
So anyway, git itself is already federated, but all the extras GitHub offered are not: tickets (bug reports, “issues”), wikis (but documentation often is part of a repository and so a bug in the documentation requires a new commit and possibly a new release just like a bug in the software itself), tech notes (if these are different from the documentation, as they probably should be), and so on. These things are not part of git itself and *these* are the things that need federation. But you could keep them in a separate git repo and then it would “just work”, right?
So perhaps we just need a piece of server side software that knows how to display git repos in various “flavors” – source code, tickets, wiki; and an easy way to create new repository tuples. And then you’re done! Except for the user interface (UI) of course. But you know us: UI always comes last. 😂
Fossil would support all that but it’s not git. I keep returning to Fossil. The only part that makes me sad is that it isn’t git. I know, git can be arcane and confusing, but for the moment, it is super popular and you can find all the help you need out there. At the office, everybody uses it and I benefited greatly from using git for my private projects. So... no Fossil at the moment, I think.
@deshipu reminded me of Hatta Wiki: “It requires no configuration and can be easily started in any Mercurial repository.” So clearly, the various elements already exist. The ones I stumbled across using git as a backend were Gollum, Gitit, Ōlelo, G-Wiki.
Perhaps all the software we need is already there?
As for tickets, some projects like Emacs use old school email based bug reporting and managing. It feels increasingly weird to use, though.
What about review mechanisms? I’ve seen many variants:
Do you actually use the PR review mechanism GitHub or GitLab provide? For my small private projects, I just look at the file diff in the web interface but I could just as well pull from a remote repository and look at it locally. Thus, I’m not sure we need it.
#GitHub #Programming