Stagit-gopher: a static git page generator for gopher

Last modification on

Stagit-gopher is a static page generator for Gopher. It creates the pages as static geomyidae .gph files. Stagit-gopher is a modified version from the HTML version of stagit.

Read the README for more information about it.

I also run a gopherhole and stagit-gopher, you can see how it looks here: gopher://codemadness.org/.

sacc is a good Gopher client to view it.

Clone

git clone git://git.codemadness.org/stagit-gopher

Download releases

Releases are available at: https://codemadness.org/releases/stagit-gopher/ and https://dl.2f30.org/releases/stagit-gopher-*.tar.gz

Features

  • Log of all commits from HEAD.
  • Log and diffstat per commit.
  • Show file tree with line numbers.
  • Show references: local branches and tags.
  • Detect README and LICENSE file from HEAD and link it as a webpage.
  • Detect submodules (.gitmodules file) from HEAD and link it as a webpage.
  • Atom feed log (atom.xml).
  • Make index page for multiple repositories with stagit-gopher-index.
  • After generating the pages (relatively slow) serving the files is very fast, simple and requires little resources (because the content is static), a geomyidae Gopher server is required.
  • Security: all pages are static. No CGI or dynamic code is run for the interface. Using it with a secure Gopher server such as geomyidae it is privilege-dropped and chroot(2)'d.
  • Simple to setup: the content generation is clearly separated from serving it. This makes configuration as simple as copying a few directories and scripts.
  • Usable with Gopher clients such as lynx and sacc.

Cons

  • Not suitable for large repositories (2000+ commits), because diffstats are an expensive operation, the cache (-c flag) is a workaround for this in some cases.
  • Not suitable for large repositories with many files, because all files are written for each execution of stagit. This is because stagit shows the lines of textfiles and there is no "cache" for file metadata (this would add more complexity to the code).
  • Not suitable for repositories with many branches, a quite linear history is assumed (from HEAD).
  • Relatively slow to run the first time (about 3 seconds for sbase, 1500+ commits), incremental updates are faster.
  • Does not support some of the dynamic features cgit has, like:
    • Snapshot tarballs per commit.
    • File tree per commit.
    • History log of branches diverged from HEAD.
    • Stats (git shortlog -s).

This is by design, just use git locally.