what if my git host were a static site generator?
44 points by easrng
44 points by easrng
The classic implementation of this idea is stagit or perhaps it’s more like browsegit
[Annoyingly, “static web site” used to mean “no dynamic HTML templating” but now it sometimes means “no server-side HTML templating but lots of client-side HTML templating”.]
I would expect an in-browser git client to be really slow since it requires lots of back-and-forth chatting over a high-latency link. And I would expect a dumb-protocol client to make the server load worse since it doesn’t have the smart-protocol optimizations. Whether this is a win against bots or not depends on how much the bots are emulating a full-fat browser session; unfortunately the arms race against things like Anubis is pushing the bots in that direction.
Interesting references !
This feels somewhere in between : some stuff must be generated (like stagit) and some is directly fetched from the .git folder (like browergit).
This is cool and very pretty! I'm the author of legit, which is fully server rendered in Go + HTML templates. It's... been a while since I touched it but shouldn't be terribly hard to get my agent to clean it up.
i was actually using legit on git.t4t.associates before i wrote sorcery! i patched it to support owner/repo repo names though :D
when it receives an update to a git repo, it will rebuild a bunch of on-disk HTML for that. … this allows us to pay a fixed upfront cost for serving many future requests
Alternatively it could generate the HTML lazily: generating each file when it’s requested but missing, and clearing the entire cache directory whenever the repo updates.
author here!! the reason i didn't do this is because the initial design was daemonless (it was just a generator that ran on git post-receive + nginx for serving), and i still want to support that mode of operation: consider a thing that builds your git repo view & then uploads it to a static CDN! the generator does do incremental builds, and it will reuse unchanged highlighted file views from a previous commit
It looks really nice, and it feels nice even on my phone (btw, unlike GH).
I'm not completely sure what is this build on. Looks like it could be rust, but there's a 29% of ts that kind of puts me off. May make sense, that the fronted is written in ts, and I'm probably silly... but I don't want to touch that stack in my personal projects.
This is great, and right on time as my Gitea instance is being hammered to bits by LLM traffic. Now to find a good replacement for a self-hosted CI system...
I'm looking for people who have problems with git forges and scrapers and would like to test something potentially different. Let me know in case you have time to play. Email in the profile.
Serving an SPA instead of Anubis feels like the better way of forcing the client to do some proof of work!
Moreover if you need the SPA to navigate, it forces the client to make multiple requests, which can be rate-limited if needed (I don't think the residential proxies share a browser).
Darcs doesn’t have branches/channels so it cat be hosted statically, without any special HTTP daemon or static generation tool, out of the box. That’s how I’ve been using it since it’s just so lightweight to slap any reverse proxy—H2O in my case—in front of a repository.
Some other interesting prior art is Abbaye. I thought the author was here, but I'm not sure.
Also git-arr
I expect there are a lot of these
Ah, I mention Abbaye because it doesn't focus on the code browsing part. It provides one, but by default it is off and limited to branch tips and tags. Abbaye focuses more on providing an equivalent to the GitHub release pages, and seems to integrate well with publishing docs, etc.