Git servers like Github and Gitlab are a complete mess, because they try to appeal to every use-case. If they were a person, they would be someone who says 'yea, me too' so reflexively that everyone gives them pitying looks. Each could do better as a more specialized service for a particular use. But we don't need specialized git servers to provide the main feature - discoverability for a particular purpose. Anyone could make an overview with a little web-scripting and some gaffer-tape, since most of what people use to peruse software projects is just the README file and a few tags.

The Bloat

Gitlab has to be among the worst offenders here. The main public instance has a button labelled 'explore' which lets people find interesting projects to contribute to. It helps maintainers and contributors. But Gitlab doesn't care much about exploration - it cares about big corporations paying per user to run their own personal Gitlab instance. So the 'explore' button takes a back-seat to the real customers.

Nowadays, Gitlab and Github want to sell chatbots, so the front-page... wait, this rant will not become side-tracked by the blabbering bots.

Ahem

Where was I?

MESS.

Gitlab's side-bar has - by default and in all projects - has a place for your Docker containers, another for your terraform modules, a place for merge requests and wikis, for help-desks and incident reports. Some of these might sound sensible. The world needs better documentation, so perhaps 'here is your default wiki, hint, hint' could prompt those mysterious devs to spill some of the secrets of how their 'open source' software works. But even those sensible wiki buttons stop sounding sensible once they sit beside the alternative.

Feature Breakdown

Wikis

Some projects build documentation by compiling man-pages. Others just have a bunch of markdown inside a directory. Many link to an external wiki, and for good reason - electing to remain on Gitlab or Github means they come with a default wiki-style, designed for the web before anything else.

The recutils documentation comes in standard HTML (as a series of links), chonky HTML (as one massive page), PDF, and in plenty of other formats. Once downloaded, you can read the docs as info pages. Nobody knows that info pages are, but idea basic idea is excellent: someone writes the documentation once and everyone reads it however they want. You won't get that kind of setup with Github, where they want your wiki stuck in their personal format, only available on Github.

Editors

Without Gitlab's code editor I would not have received half the contributions to BIND. It lets normal users just sign into a website, type words, and leave a little message when they save their changes. Lowering the barrier to entry helps me enormously, and it could help any collaborative writing project. But I don't see how it helps coding projects.

The web interface guarantees that the committer has not tested the code outside of the pipeline. But the pipeline does not just make itself available - it becomes the only way to test. Someone committing code via the web interface has to wait for the full pipeline to complete, and hope that the pipeline checks for precisely the problems they might have introduced. It allows no new dependencies - not a single extra library or submodule - unless the code also wishes to compile a new Docker container, send it up, and then edit the .gitlab-ci file with full details.

The suggested workflow suggests neither 'work' nor 'flow'.

Pipelines

A .github/workflows/ directory has no business being inside any repository. These files serves Github, not the developers. Only Github has an interest in keeping these files inside the repository to act as a subtle kind of gravity, pulling the repository back home.

The same instructions could live in a separate repository, just as people have separate wikis. Platform specific instructions could, by default, pull down the repository's latest commits and run through the build instructions, or keep templates for pull requests.

Alternatively, build systems might use a GUI, just like one's avatar and account notes which live under settings menus. Pipelines for a specific platform don't necessarily require a git repository.

Issues

Some maintainers want a public issues page, but other maintainers ignore their issues page for years. Better to have a section stating 'do not send your bugs, I don't care', then hosting an infertile to-do list.

Just like the wikis, the standardized to-do lists prohibit more natural solutions. Some projects might want a public issues board with a dragon-drop interface. Others might just use another git repository with plain-text files like the Erlang Ticketing System.

Features of a Catalogue

None of the git services work for every project, but there's one feature that works for everyone: stalking. Looking at stars, tags, and so on helps give people an overview on a projects intentions, language, safety, et c.

All the global features and services for git repositories are bad, but exploration, ratings, summaries and labels are not features of any project; they are meta-features for a catalogue of repositories. Making such a catalogue wouldn't have to involve any kind of mass migration. Anyone can make a catalogue and freely combine git repositories from Codeberg.org and 0xacab.org.

An Example: Newsraft

• Type: RSS Reader
• Tags: #TUI #RSS #Atom
• Language: C
• Stars: 196
• Documentation: man page, also present as a website.
• Issues: Instructions to file a bug are here.
• Download: by package manager.

...and of course, the project's README.md file. Any project which doesn't have one clearly doesn't want to be understood, and people looking around available projects shouldn't have to spend time looking at it.

The Newsraft repository on Codeberg has a releases page, but it has nothing you can install, just a history of source-code. We can leave this redundant 'feature' behind when presenting Newsraft.

A Minimal Implementation

One could make a decentralized git-stalking, repository-exploring website with just a few markdown scripts. This makes it far easier to start the project than more ambitious notions like Radicle, which seek to offer a full alternative to the big names.

For an example of a static site (with just one person's projects) check out repo rat.

Splitting Catalogues

Even this minimal static site would allow for an important site-feature: focus.

• One catalogue could have useful, ready-to-go software downloads.
• Another might focus on group writing (hopefully with a link to sign-in somewhere and write a branch in the web browser).
• Others can focus only on databases.

A few sites with catalogues of git repositories would be all it takes to make git projects truly distributed.

Pull Requests Across Servers

This leaves the question of how people work together across different servers. Most people who like code have become used to a particular interface when working with others.

One night, happily tapping out a bash script, I leaned over the table tell someone I'd fixed something in there project, and which branch to look at. They replied "Can you make a pull request?".

"Yes", I said. "This is a request. I am asking you to pull. You now have a pull request".

Somehow, people have forgotten that the pull request is literally just a request to fetch someone's changes and merge them into the primary branch. So perhaps some people will feel surprised at the concept of pull requests sent from different servers, but git makes the process easy. You can simply email someone and say where your remote is, and what you want them to pull with a single command:

1git request-pull HEAD^^ origin all

The HEAD^^ means 'last two commits', but you could as easily say all^^, which means 'branch all, last two commits'. Once done, that spits out an email:

 1The following changes since commit d263eba235941d40d9dba3231383a3e0b645439f:
 2
 3  Abbreviation: XP (2026-06-01 23:00:02 +0200)
 4
 5are available in the Git repository at:
 6
 7  ssh://soft.dmz.rs:2222/mkdots all
 8
 9for you to fetch changes up to a09d08d908b393afb542d6ed5a9189da6aa4b2cd:
10
11  Vim: set file encoding (2026-06-02 00:01:18 +0200)
12
13----------------------------------------------------------------
14Malin Freeborn (2):
15      GPG: place default keyserver
16      Vim: set file encoding
17
18 home/gnupg/gpg.conf | 2 ++
19 home/vim/vimrc      | 2 ++
20 2 files changed, 4 insertions(+)
21 create mode 100644 home/gnupg/gpg.conf

You can copy-paste that into any email client, without setting anything up.