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.
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 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.
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.
fanf | 10 hours ago
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.
oliverpool | 9 hours ago
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).
snej | 11 hours ago
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.
char | 10 hours ago
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
adamshaylor | 7 hours ago
This sounds a lot like ISR, which is cool in theory but complicated in practice.
reidrac | 10 hours ago
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.
icy | 7 hours ago
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.
char | 6 hours ago
i was actually using legit on git.t4t.associates before i wrote sorcery!
deuill | 10 hours ago
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...
[OP] easrng | 9 hours ago
You probably could use gitea for authenticated views and this for public views
viraptor | 6 hours ago
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.
oliverpool | 9 hours ago
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).
toastal | 8 hours ago
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.
koala | 7 hours ago
Some other interesting prior art is Abbaye. I thought the author was here, but I'm not sure.
singpolyma | 5 hours ago
Also git-arr
I expect there are a lot of these
erock | 5 hours ago
Adding another one to the list: https://pgit.pico.sh/