what if my git host were a static site generator?

The author has been operating multiple personal Git servers for nearly half of their life, enjoying the challenge of managing their own dev infrastructure. Over time, they transitioned from Gogs, Gitea, to Forgejo, and have deployed GitLab/Forgejo several times for various groups. However, their Forgejo server is consistently running out of disk space due to the software crashing while repacking Git repositories that haven't updated, and it struggles under high load from scrapers.

The author desires a simpler experience and wishes to expose only the features they will actually use. Forgejo and similar platforms come with excessive features like issues, PRs, releases, and wikis, which they do not require. They are concerned about the philosophy of the open web and the intrusive nature of JavaScript challenges, like those used by Anubis, to block scrapers.

One proposed alternative is to run a static site generator for Git hosting. When a Git repository is updated, the generator rebuilds static HTML files for the repository, including an overview page, the directory tree of each branch, and syntax-highlighted source code renderings. This approach would pay a fixed upfront cost for serving many future requests, making it resilient against scraper load.

The generator would omit historical views of the repository and serve the .git directory directly, implementing a basic read-only Git client in JavaScript. Additional JSON data would be emitted to aid the client-side Git client.

To further optimize performance, the author suggests providing a server-side route to fetch specific Git objects by a list of object IDs, returning a simple binary "Git object bundle" format. This would alleviate the burden of navigating compressed packfiles on the client side. The author also mentions implementing "smart fetch" modes to traverse for referenced OIDs for a given access pattern, optimizing roundtrips even for loose object repositories.

In essence, this setup would turn the Git host into a read-only Git repo viewer, focusing solely on providing a rich client-side experience for browsing repository history. This approach would be more secure, as the Git server only needs to ensure the SSH daemon is secure, and the user experience would be optimized through smart fetching and lightweight JavaScript.