Gitmal - a static pages generator for Git repos
131 points by antonmedv
131 points by antonmedv
Since everything is just static HTML, Gitmal gives you a super-fast way to browse your repos. Add a simple post-receive hook, and it updates automatically every time you push. Bonus: Gitmal works entirely without JavaScript!
This shows very well how fast GitHub could be if they wanted to.
GitHub in 2010 showed how fast GitHub can be. Seriously, it used to be very fast, very responsive.
I'm not sure if it's the glut of React that's been stapled on in the past few years that has naturally bogged everything down, or if it's developers who are incentivized to make the site more complex rather than more usable or more responsive. Likely a combination of both (and other things, she says, waving in Microsoft's direction)
This. I dare say it was widely used because it was so good, as is the case with many innovative services that eventually get enshittified.
I'm pretty sure you're a familiar face from the macsb group back in the day, and you likely remember as well as I do how bleak it was to try hosting a private repository/forge for a small team pre-github. Services for that weren't much of a thing, and self-hosting wasn't great either. When github came along, I remember being jealous of people who could use it. We were very small, but we needed to have a couple of Windows developers, and git was not yet reasonable for them to use. We wound up self-hosting mercurial, bugzilla and mediawiki on a VPN.
github felt miles better and a great deal less work than what we needed to do at the time, and we'd have been happy to pay them for what they had if it'd worked for our whole team. It was very good.
Yes — whoa, macsb! An oldie but a goodie.
I recall Trac being really great for SVN and allowing teams a lot of interlinked niceness like issues, commits, and mentions. But GitHub was miles beyond when it arrived. I'd move projects to Git just so they could use GitHub.
Sorry to advertise my own stuff on your submission Anton, but other people might be interested in more tooling for static sites.
I recently I've made a static site generator specifically for the wikis hosted on man.sr.ht because I wanted something a little more expressive as documentation for my library.
It has the basic functionalities of such generators: builds HTML from Markdown, builds a table of contents, builds a search index, etc. I think the only feature that I haven't seen anywhere else is to build web optimized versions of the images in the wiki, with progressive loading in the HTML.
The project is uninspiredly called staticman and if you want to see the end result there's the GoActivityPub project wiki.
staticman looks neat!
It would be helpful to add a link to the go-ap wiki from the staticman README though, as example.
Thanx. :) Maybe I'll add a screenshot, I don't want to link the two too much.
[edit] In the end I added a link to the README like you suggested. I've also given more details about how the tool can be used.
I think it is kind of ironic that a static page no-js git repo generator's git repository is hosted on a git frontend (GitHub) which notoriously does not work without JavaScript. Good job though, and looks good.
Yes! I was expecting this comment).
I host all my repos on GitHub, and I like GitHub’s collaborative features. And I’m obviously collecting stars 🌟. I plan to use Gitmal as a backup host for my git repos.
Cool! Would it be possible to add a “Clone” button? Don't see it in your example projects.
The url itself could be made clonable with an added build step: https://log.pfad.fr/2023/git-clone-all-the-things/ (a button would be nice still)
Yes, I am talking about button
This is very cool, and I really appreciate the fairly short list of dependencies. Is the compilation incremental - i.e. when running from a post-receive hook, will it avoid regenerating pages that haven't changed?
Gitmal will regenerate everything. Maybe I will add incremental builting in the future. But I see problems with tags tracking.
Yes, especially considering that a bigger repository seems to be slow to generate (e.g., the README.md says that the Kubernetes repo takes 25 minutes to generate in a MacBook Air m2). I want to test this with nixpkgs just for the fun.
Nice, I'd like to know how much it takes for nixpkgs (I guess a lot).
K8s has a lot of files! After generation it's around 160,000 =).
Interesting, it panic'ed:
$ time gitmal -gzip -minify .
> nixpkgs: 16 branches, 0 tags, 905516 commits
> [1/16] nixpkgs@bump-retroarch
[########################] 50031/50031 (100%) blobs for bump-retroarch
[########################] 35160/35160 (100%) lists for bump-retroarch
[########################] 9027/9027 (100%) commits for bump-retroarch
> [2/16] nixpkgs@bump-rtorrent
[########################] 49748/49748 (100%) blobs for bump-rtorrent
[########################] 34953/34953 (100%) lists for bump-rtorrent
[########################] 8935/8935 (100%) commits for bump-rtorrent
> [3/16] nixpkgs@fix-437872
[########################] 49634/49634 (100%) blobs for fix-437872
[########################] 34861/34861 (100%) lists for fix-437872
[########################] 8898/8898 (100%) commits for fix-437872
> [4/16] nixpkgs@fix-444156
[########################] 48968/48968 (100%) blobs for fix-444156
[########################] 34475/34475 (100%) lists for fix-444156
[########################] 8638/8638 (100%) commits for fix-444156
> [5/16] nixpkgs@fix-449393
[########################] 49154/49154 (100%) blobs for fix-449393
[########################] 34597/34597 (100%) lists for fix-449393
[########################] 8737/8737 (100%) commits for fix-449393
> [6/16] nixpkgs@fix-463271
[########################] 49915/49915 (100%) blobs for fix-463271
[########################] 35047/35047 (100%) lists for fix-463271
[########################] 8987/8987 (100%) commits for fix-463271
> [7/16] nixpkgs@fix-logger-level
[########################] 49461/49461 (100%) blobs for fix-logger-level
[########################] 34797/34797 (100%) lists for fix-logger-level
[########################] 8853/8853 (100%) commits for fix-logger-level
> [8/16] nixpkgs@fork
[########################] 8/8 (100%) blobs for fork
[########################] 4/4 (100%) lists for fork
[########################] 1/1 (100%) commits for fork
> [9/16] nixpkgs@master
[########################] 50087/50087 (100%) blobs for master
[########################] 35205/35205 (100%) lists for master
[########################] 9055/9055 (100%) commits for master
> [10/16] nixpkgs@nixos-rebuild-ng-do-not-handle-exceptions
[########################] 49171/49171 (100%) blobs for nixos-rebuild-ng-do-not-handle-exceptions
[########################] 34618/34618 (100%) lists for nixos-rebuild-ng-do-not-handle-exceptions
[########################] 8749/8749 (100%) commits for nixos-rebuild-ng-do-not-handle-exceptions
> [11/16] nixpkgs@ollama-model-loader-add-network-online
[########################] 48948/48948 (100%) blobs for ollama-model-loader-add-network-online
[########################] 34480/34480 (100%) lists for ollama-model-loader-add-network-online
[########################] 8625/8625 (100%) commits for ollama-model-loader-add-network-online
> [12/16] nixpkgs@remove-nixos-rebuild
[########################] 50074/50074 (100%) blobs for remove-nixos-rebuild
[########################] 35200/35200 (100%) lists for remove-nixos-rebuild
[########################] 9051/9051 (100%) commits for remove-nixos-rebuild
> [13/16] nixpkgs@retroarch
[########################] 50026/50026 (100%) blobs for retroarch
[########################] 35158/35158 (100%) lists for retroarch
[########################] 9027/9027 (100%) commits for retroarch
> [14/16] nixpkgs@staging-nixos
[########################] 49634/49634 (100%) blobs for staging-nixos
[########################] 34861/34861 (100%) lists for staging-nixos
[########################] 8898/8898 (100%) commits for staging-nixos
> [15/16] nixpkgs@zhf/haskellPackages-2015-to-2024-darwinFailure
[########################] 49811/49811 (100%) blobs for zhf/haskellPackages-2015-to-2024-darwinFailure
[########################] 34985/34985 (100%) lists for zhf/haskellPackages-2015-to-2024-darwinFailure
[########################] 8970/8970 (100%) commits for zhf/haskellPackages-2015-to-2024-darwinFailure
> [16/16] nixpkgs@zhf/haskellPackages-2015-to-2024-darwinFailure-pt2
[########################] 49811/49811 (100%) blobs for zhf/haskellPackages-2015-to-2024-darwinFailure-pt2
[########################] 34985/34985 (100%) lists for zhf/haskellPackages-2015-to-2024-darwinFailure-pt2
[########################] 8970/8970 (100%) commits for zhf/haskellPackages-2015-to-2024-darwinFailure-pt2
> generating commits...
[########################] 905516/905516 (100%) commits
panic: gitdiff: line 1: git file header: invalid syntax
goroutine 1 [running]:
main.main()
/home/<user>/.go/pkg/mod/github.com/antonmedv/gitmal@v1.0.0/main.go:240 +0x17ae
gitmal -gzip -minify . 7812.14s user 2024.80s system 678% cpu 24:09.92 total
Commit that I used from nixpkgs: 3d88bee6a315d4515103239be46d84c2f7f5c73e.
Thanks! I will try to understand what is the problem with git diff parsing: https://github.com/antonmedv/gitmal/issues/2
Obviously this is a brand new project, and a lot of corner cases are not covered. =)
That looks perfect (and stagit looks good too) for what I was thinking a few days ago. Sometimes you want to share your projects but aren't looking for contributors, bug reports, feature requests or community. You've made something, you share it and because that's how you behave, but you're not trying to take it further. And bonus point: this is probably less affected by abusive crawlers.
One thing I couldn't see is whether it's possible to limit the history rendering depth. I can see a use to showing only the last commit for each ref and no further history.
kinda cool to use this as an adhoc notes system when you just need something online. I will probably forget this tool when I need it.
i run a https://github.com/charmbracelet/soft-serve instance for a few private projects... this might pair well...
just need a lightweight UI for having discussions on pull/merge requests, the email patch process is still too unconventional
I've been recently looking into frontends for Git repos. This looks cool! And contains a way to link to a specific line in a file.
Is there a way to have permalinks to a specific line in a file in a commit? I'd guess the answer is "Unless you want to generate static pages for each commit, no. Not without Javascript", but still wanted to ask.
Is there a way to have permalinks to a specific line in a file in a commit?
Actually, it is possible. I was thinking about adding this feature as well! A file in a git diff can also have linkable line numbers.
For anyone else curious, I bet the CSS :target pseudo-class would work for this, with ids for each line.
Took about 20 minutes to generate a PHP-based repo browser using LLMs. While rough around the edges, it covers the bare essentials, and allows explicit ordering of repos (for prioritization). It's fairly fast, responsive, but the code is not pretty. I was using GitList until it nearly took down my shared host (lots of memory usage, huge cache files). No JavaScript was harmed or used in the creation of this software. No hooks necessary, it'll recognize newly added repos automatically.
If there's interest, I'll post the LLM-generated code.
Gitmal main feature is generation of static html files. Yes, I could instead create another git view server. But it will be slower, and more importantly less secure. I would not trust LLM generated php script to handle exec commands on my server.
Took about 20 minutes to generate a PHP-based repo browser using LLMs.
Good for you. Gitmal took me a few weekends and couple of evenings to develop.