Comment by wahern | Hacker News Reader

Comment by wahern | Hacker News Reader

> People can ‘git clone’ my code, and there’s a web-based browsing interface (the basic gitweb) for looking around without having to clone it at all.

I host my own public Git repositories, but statically--read-only, no HTML views. I don't want to run any specialized server-side code, whether dynamic or preprocessed, as that's a security vector and system administration maintenance headache I don't want to deal with. You can host a Git repository as a set of static files using any web server, without any special configuration. Just clone a bare repo into an existing visible directory. `git update-server-info` generates the necessary index files for `git clone https://...` to work transparently. I add a post-receive hook to my read-write Git repositories that does `cd /path/to/mirror.git && git fetch && git --bare update-server-info` to keep the public repo updated.

In theory something like gitweb could be implemented purely client-side, using JavaScript or WASM to fetch the Git indices and packs on-demand and generate the HTML views. Some day I'd like to give that a try if someone doesn't beat me to it. You could even serve it as index.html from the Git repository directory, so the browser app and the Git clone URL are identical.

I like this idea quite a bit. It's lightweight and read-only, which makes it far easier to host. I'm in the process of publishing some of my own repositories so I'm going to give this a try.

I haven't looked into mich details of gibt's packing, but for a big repo you probably don't want a client to download it all nor do a huge amount of http range requests for being able to show the summary page. You think that would work well or would this need at least some caching layer?

You could write a static site generator to generate a website from the repo, so you’re still just serving static files.

I once explored doing just that: https://github.com/nhanb/boast

However I never got around to finishing it, mainly because I couldn't decide on where to stop: should I also generate commits from all non-master branches etc.

I flirted with the idea of a browser-side repo viewer too, but re-implementing git packfile parsing in js didn't seem like something I'd want to spend my time on, so I moved on. Glad to see others pondering the same thing though.

That does get intense pretty quickly, if you're generating a source and commit/diff pages for every file * every commit. Probably just single commits would make the most sense and then a source browser for each branch.

That said, JavaScript libgit2 is a thing [1], so doing it "properly" in a client app is totally possible.

[1]: https://github.com/libgit2/libgit2/issues/4376 | https://github.com/petersalomonsen/wasm-git

I’d go with a combined approach. Static pages for every file on master, JS for everything else. This way master branch loads instantly, but other branches (with diff, blame etc) are also available.

Hmmm, I might give it a go one day.

Would the js pages really take much longer to load than static? Fetching a few packfiles and hydrating a template should be very fast.

Probably. We’re looking at three roundtrips here: one to fetch the HTML, one for the JS, and at least one for the packfiles (and that’s if you can do that in parallel). If the latency is high, the result can be... not great. HTTP/2 should help with this a bit, but it’s better to not have this problem at all IMO.

Of course, there’s also the argument that if you’re self-hosting a repo, you’re more likely to care about users that have disabled JS (which is a good idea, tbh).

If you render the repo home/tree/readme statically but serve the JS application upfront with that, then successive clicks into files/commits/diffs will only have to pull packfiles, and then only if the content isn't already present locally. Packfiles are obviously immutable so they can be set for infinite caching, which should mean that even successive visits could be pretty speedy.

Yeah, the question is basically which entry pages you want to support. I think it’s nice to be able to link to a particular file on the master branch and have it load instantly, too. Loading older verisions, on the other hand, has its uses but is less important.

For a repo with thousands of files, it might make sense to limit entry pages to only directories and .md files (and other prose files), which are more likely to be linked to. You can also skip shipping a Markdown renderer this way!

Nice work. This has been on my bucket list to make for a few years. If you ask me, yes: make an .html file for each non-orphan commit on each branch.

https://git.trevorbentley.com/itsy-gitsy/ (I don't use so not sure how good it is, just noting)

Getting the tree (at the root) is only a few requests (get the refs or HEAD, get the relevant commit, get the tree ID from that). If pack files aren't involved then that's literally 3 requests. Pack files make this more complex, but careful caching and range requests could reduce that to as few as around 5-8 extra requests (doing binary searching via HTTP range requests). I don't think even libgit2 has APIs for range requests on pack files though, so this would need a special library (or patching libgit2...).

There's also various optimizations on the git side like bitmaps[1] and commit-graphs[2]. If this a bare repo on the server side it shouldn't be a problem to make sure it is in a particular format with receive hooks.

That's just displaying a file listing though. Displaying what GitHub displays with the last change of each file is more complex, maybe the commit graph could be used so the client wouldn't have to fetch everything itself.

  [1]: https://git-scm.com/docs/bitmap-format
  [2]: https://git-scm.com/docs/commit-graph

Reply on news.ycombinator.com