5 ms·

Stagit – A static Git page generator

106 points by raldu 9y ago

bachmeier 9y ago
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.
- ldonley 9y ago
  It looks like this is the GitHub for the project: https://github.com/oxalorg/stagit https://github.com/oxalorg/stagit
  - matthewbarram 9y ago
    Definitely looks pretty similar
  - daptaq 9y ago
    Actually http://git.2f30.org/stagit/ 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)
- deleted 9y ago
  [deleted]
- c22 9y ago
  I believe the website is an example of its output.
- exDM69 9y ago
  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.
  - daptaq 9y ago
    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"
- fao_ 9y ago
  The README is right at the top of the page ?
wrigby 9y ago
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?
- sdesol 9y ago
  > 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/vscode#b%3Dgithub%3AMicrosoft%2Fvscode%3Amaster%26t%3Dcommits 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.
  - mrmondo 9y ago
    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.
    - sdesol 9y ago
      > 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.
chriswarbo 9y ago
Very nice! Personally I'm using git2html (e.g. see http://chriswarbo.net/git/git2html/git 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.
- DorothySim 9y ago
  > 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 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-viewer/index.html https://github.com/yonran/git.js/blob/master/demos/repo-view...
trqx 9y ago
same tool for gopher: http://git.2f30.org/stagit-gopher/file/README.html http://git.2f30.org/stagit-gopher/file/README.html
fredo699 9y ago
Or just use mercurial, and it's bundled right in by default :)
nishs 9y ago
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/ https://gerrit.googlesource.com/gitiles/
progman 9y ago
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); }}}
kpcyrd 9y ago
git clone git://git.codemadness.org/stagit Can we please stop doing that? Use https:// https:// or anonymous ssh.

106 points by raldu 9y ago

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.

ldonley 9y ago
It looks like this is the GitHub for the project: https://github.com/oxalorg/stagit https://github.com/oxalorg/stagit
- matthewbarram 9y ago
  Definitely looks pretty similar
- daptaq 9y ago
  Actually http://git.2f30.org/stagit/ 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)
deleted 9y ago
[deleted]
c22 9y ago
I believe the website is an example of its output.
exDM69 9y ago
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.
- daptaq 9y ago
  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"
fao_ 9y ago
The README is right at the top of the page ?

wrigby 9y ago

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?

sdesol 9y ago
> 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/vscode#b%3Dgithub%3AMicrosoft%2Fvscode%3Amaster%26t%3Dcommits 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.
- mrmondo 9y ago
  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.
  - sdesol 9y ago
    > 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.

chriswarbo 9y ago

Very nice! Personally I'm using git2html (e.g. see http://chriswarbo.net/git/git2html/git 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.

DorothySim 9y ago
> 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 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-viewer/index.html https://github.com/yonran/git.js/blob/master/demos/repo-view...

trqx 9y ago

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

fredo699 9y ago

Or just use mercurial, and it's bundled right in by default :)

nishs 9y ago

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/ https://gerrit.googlesource.com/gitiles/

progman 9y ago

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); }}}

kpcyrd 9y ago

git clone git://git.codemadness.org/stagit Can we please stop doing that? Use https:// https:// or anonymous ssh.