Stagit – A static Git page generator(git.codemadness.org)
git.codemadness.org
Stagit – A static Git page generator
https://git.codemadness.org/stagit/
21 comments
> 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...
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/
https://gerrit.googlesource.com/gitiles/
You can have something like that also in your shell. Just apply
git log --reverse | perl githead.pl
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); }}}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'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.
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:
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"
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.
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"
It looks like this is the GitHub for the project: https://github.com/oxalorg/stagit
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)
Definitely looks pretty similar
[deleted]
I believe the website is an example of its output.
The README is right at the top of the page ?
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.
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.
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.
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...
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.