A developer introduces sorcery, a git repo viewer built like a static site generator rather than a full git forge. It rebuilds static HTML overview pages, trees, and syntax-highlighted source on push, while serving the raw .git directory alongside a client-side JavaScript git client for historical browsing, avoiding scraper-hostile solutions like Anubis. It intentionally omits accounts, issues, PRs, and wikis, staying read-only while writes happen over git-over-ssh with a separate ForceCommand tool called sorcery-ssh. The design optimizes for read-heavy workloads on tiny personal servers, using techniques like a custom binary git object bundle endpoint to avoid multi-hundred-megabyte packfile fetches.
Table of contents
publishing to the open webgit repo views with minimal server computenon-featuresso, yeahCommunity take
Updated
16
comments
The write-up drew an enthusiastic reception from people who appreciate a lightweight, static alternative to full git forges, with lots of prior-art comparisons and technical nitpicking about caching and the client-side git approach.
55% positive
35% mixed
10% skeptical
Deep diveQuestions this post answers
How can I serve a git repo viewer without running into scraper load problems on a small server?
Build the repo viewer as a static site generator: on each push, rebuild fixed HTML pages (overview, tree, syntax-highlighted source for branch tips) so serving becomes a cheap sendfile-and-forget operation rather than dynamic computation per request. This avoids resource exhaustion under scraper load without needing a JavaScript proof-of-work gate like Anubis, since reads vastly outnumber writes in typical git browsing workloads. daily.dev surfaces build-vs-buy tradeoffs like this for developers weighing self-hosted infrastructure options.
Why is directly fetching git packfiles over a network so slow for viewing repo history?
Git stores objects compressed in delta-encoded packfiles, so naively fetching a packfile index just to view one commit's diff in a large repo like linux.git can require over 400MiB of bandwidth. Smart range-scanning avoids that but kills cache hit rates and creates request waterfalls, since later fetches depend on data from earlier ones, making history browsing feel slow on high-latency connections. developers debugging git protocol performance can track write-ups like this on daily.dev.
What is the difference between a git forge and a git repo viewer?
A git repo viewer, unlike a full git forge such as Forgejo or GitLab, omits user accounts, SSH/GPG key management, issues, and pull requests, staying entirely read-only for browsing code. Writes happen separately through git-over-ssh with a ForceCommand tool that autocreates repos on first push, keeping the public-facing viewer's attack surface limited to whatever serves static files and sshd. daily.dev helps developers weighing forge features against lightweight repo-browsing setups compare real-world tradeoffs.
Share this post