Stagit – A static Git page generator | Hacker News Reader

Stagit – A static Git page generator

git.codemadness.org

106 pointsraldu19 comments

This is not a very informative link. Would be nice to have a description of what it is and why the reader should be interested in it.

It looks like this is the GitHub for the project: https://github.com/oxalorg/stagit

Definitely looks pretty similar

Actually http://git.2f30.org/stagit/ is the real host, what you linked was just a mirror. If you go up one level on the site, you can find a list of projects hosted by the 2f30 team, including stagit, which was made by Hiltjo Posthuma (one of the Suckless guys, iirk)

I believe the website is an example of its output.

It's a Git web frontend like cgit or gitweb, but it's statically generated and this is it self hosted.

The title is descriptive and there's a more info in the README.

Perhaps the default view should be README and file listing like in GitHub, so it would have been even more obvious.

This part of the README pretty much tells you everything you need to know:

    Features
    --------
    - Log of all commits from HEAD.
    - Log and diffstat per commit.
    - Show file tree with linkable 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-index.  
    - After generating the pages (relatively slow) serving the files is very fast, 
      simple and requires little resources (because the content is static), only     144 a HTTP file server is required.
    - Usable with text-browsers such as dillo, links, lynx and w3m.

    Cons 
    ----
    - Not suitable for large repositories (2000+ commits), because diffstats are     152 an expensive operation.
    - 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.     
      - file tree per commit. 
      - history log of branches diverged from HEAD.
      - stats (git shortlog -s). 
        this is by design, just use git locally.

>Perhaps the default view should be README and file listing like in GitHub, so it would have been even more obvious.

This would actually be pretty easy go do, since one would just have to re-link "index.html" from pointing to "log.html" to "./file/README.html"

The README is right at the top of the page ?

Very nice! Personally I'm using git2html (e.g. see http://chriswarbo.net/git/git2html/git ) with a few modifications. In particular, I've had to limit it to only using the HEAD commit, since the disk space becomes crazy (e.g. it seems to render the contents of every file to a separate HTML page for each commit).

I'll take a look at stagit, since it might be saner (plus the resulting pages look nicer, and I can stop maintaining my own patches to git2html).

What I'd really like to see is a JS implementation of the "dynamic" features like diffing, so rather than having to pre-compute and store them, they can be generated on demand on the client-side by fetching the required git objects, etc. over HTTP (would presumably require a clone to be accessible on the same domain as the HTML). That way, everyone gets the plain pages like now, but those enabling JS can browse repos more thoroughly.

> What I'd really like to see is a JS implementation of the "dynamic" features like diffing

That's possible. I've made something like that (dynamically fetching git info via dump HTTP server protocol) using Git.js [0] although for a different reason and it worked very well. Some caveats: the decompression must be handled in a WebWorker or the UI is stuck pretty easily. But objects can be fetched on demand so it's kind of like Microsoft's Git Virtual FS. As you've said cross origin policies apply so either have the viewer on the same site as repos or add appropriate CORS headers.

[0]: https://github.com/yonran/git.js

I see git.js even has a "repo-viewer" demo [1]. Although it's very primitive it shows the ref list and diffs.

[1]: https://github.com/yonran/git.js/blob/master/demos/repo-view...

same tool for gopher: http://git.2f30.org/stagit-gopher/file/README.html

This is great. A slightly more feature-rich alternative is Gitiles, which is used by the Chromium and Android projects.

https://gerrit.googlesource.com/gitiles/

Looks pretty nice! The readme says it's not useful for repos with >2000 commits, but I wonder if we could hack together some sort of cache for it to facilitate delta updates?

> we could hack together some sort of cache for it to facilitate delta updates?

Crunching diffs at scale is actually an extremely I/O intensive operation and I can say this from experience, since my product is doing just that. You can see an example of what I mean at

https://public.gitsense.com/insight/github?r=Microsoft/vscod...

If you scroll down, you can see how the indexed information is used. The red, green, and blue bars, denotes how many lines were deleted, added and changed. The red, green and blue bars in the second row, shows how many lines were deleted, added and changed, which were non blank/comment lines.

If you want to crunch diffs at scale, you really have to throw CPU cores, RAM and multiple SSDs at the problem. The more CPU cores, translates to more diffs that can be processed in parallel. The more RAM, translates to better Kernel page caching. And multiple SSDs in RAID 0 configuration, translates to better read and write speeds.

Do you think it’s possible to calculate the relationship between the depth of the git data and the number of I/O operations?

This is purely out of interest, our storage performs at around 2-4M random 4K read IOP/s per node and I was wondering (just for fun) how it might look thrown a good I/O crunch task like this.

> Do you think it’s possible to calculate the relationship between the depth of the git data and the number of I/O operations

It's actually pretty straight forward since you know exactly what operations has to be done. With very good I/O, you may find the CPU will become your bottleneck.

Yeah then it becomes even more interesting to me ;) especially when it comes to NUMA etc...

You can have something like that also in your shell. Just apply

  git log --reverse | perl githead.pl

where githead.pl is

  my $date, $old; while (my $line = <>) { chomp $line; next unless $line; $date = "$1 $2 $3" if $line =~ m|Date:\s+(.+?)\s+(.+?)\s+(.+?)\s+|; if ($line =~ m/^\s+/) { if ($date ne $old) { printf("%-10s%s\n",$date,$line); $old = $date; } else { printf("%-10s%s\n",'',$line); }}}

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

Can we please stop doing that? Use https:// or anonymous ssh.

Reply on news.ycombinator.com