Github and publishing Git repositories

February 23, 2018

Recently I got into a discussion on Twitter where I mentioned that I'd like a simple way to publish Git repositories on my own web server. You might reasonably ask why I need such a thing, since Github exists and I even use it. For me, a significant part of the answer is social. To put it one way, Github has become a little bit too formal, or at least I perceive it as having done so.

What has done this to Github is that more and more, people will look at your Github presence and form judgements based on what they see. They will go through your list of repositories and form opinions, and then look inside some of the repositories and form more opinions. At least part of this exploration is natural and simply comes from stumbling over something interesting; more than once, I've wound up on someone's repository and wondered what else they work on and if there's anything interesting there. But a certain amount of it is the straightforward and logical consequence of the common view that Github is part of your developer resume. We curate our resumes, and if our Github presence is part of that, well, we're going to curate that too. A public portfolio of work always tries to put your best foot forward, and even if that's not necessarily my goal with my Github presence, I still know that that's how people may take it.

All of this makes me feel uncomfortable about throwing messy experiments and one-off hacks up on Github. If nothing else, they feel like clutter that gets in the way of people seeing (just) the repositories that I'm actively proud of, want to attract attention to, and think that people might find something useful in. Putting something up on Github just so people can get a copy of it feels not so much wrong as out of place; that's not what I use my Github presence for.

(A strongly related issue are the signals that I suspect that your Github presence sends when you file issues in other people's Github repositories. Some of the time people are going to look at your profile, your activities, and your repositories to assess your clue level, especially if you're reporting something tangled and complex. If you want people to take your issues seriously, a presence that signals 'I probably know what I'm doing' is pretty useful.)

A separate set of Git repositories elsewhere, in a less formal space, avoids all of these issues. No one is going to mistake a set of repositories explicitly labeled 'random stuff I'm throwing up in case people want to look' for anything more than that, and to even find it in the first place they would have to go on a much more extensive hunt than it takes to get to my Github presence (which I do link in various places because, well, it's my Github presence, the official place where I publish various things).

Sidebar: What I want in a Git repository publishing program

The minimal thing I need is something you can do git clone and git pull from, because that is the very basic start of publishing a Git repository. What I'd like is something that also gave a decent looking web view as well, with a description and showing a README, so that people don't have to clone a repository just to poke around in it. Truly ideal would be also providing tarball or zip archive downloads. All of this should be read-only; accepting git push and other such operations is an anti-feature.

It would be ideal if the program ran as a CGI, because CGIs are easy to manage and I don't expect much load. I'll live with a daemon that runs via FastCGI, but it can't be its own web server unless it can work behind another web server via a reverse proxy, since I already have a perfectly good web server that is serving things I care a lot more about.

(Also, frankly I don't trust random web server implementations to do HTTPS correctly and securely, and HTTPS is no longer optional. Doing HTTPS well is so challenging that not all dedicated, full scale web servers manage it.)

It's possible that git http-backend actually does what I want here, if I can set it up appropriately. Alternately, maybe cgit is what I want. I'll have to do some experimentation.


Comments on this page:

From 193.219.181.219 at 2018-02-23 01:12:35:

Yes, you would use git-http-backend via CGI for the cloning (and optionally pushing), and cgit or gitweb for the web UI.

Although setting up *both on the same URL requires some ugly-looking regexen, which fortunately can be copied straight off the manpage.

---

That said, Git can clone/pull/fetch over "dumb" HTTP (as well as other dumb transports such as FTP or rsync), although it has various downsides: quite a bit slower, no progress feedback, the client can't ask for a minimal packfile – it has to cope with what's already on the server (which sometimes means downloading a 10 MB packfile even though you only need a single object).

But the upside of "dumb HTTP" mode is that it's trivial to set up; just enable foo.git/hooks/post-update.sample (and manually run it once).

---

Gogs seems to be a popular alternative – written in Go and entirely self-contained. (Though I assume it still calls git-http-backend.)

From 193.219.181.219 at 2018-02-23 01:14:34:

I forgot to mention an interesting toy hidden in Git: git instaweb

By Kring at 2018-02-23 08:48:51:

Gitlab allows you to create private repositories for free.

The lazy-in-a-bad-way alternative is to create a new organisation on GitHub for your experiments and random junk.

Gitlab is pretty good, and easy to setup if you user their Omnibus docker container.

A 20 line docker-compose.yml file works pretty well for me, and upgrading is super easy. I let it be the front-end webserver on its own IP, but I bet you can make it work behind a reverse proxy.

Upgrading is just:

$ docker-compose pull
$ docker-compose up -d

Here is the docker-compose.yml I use:

web:
        image: 'gitlab/gitlab-ce:latest'
        restart: always
        hostname: git.mydomain.org
        environment:
                GITLAB_OMNIBUS_CONFIG: |
                        external_url 'https://git.mydomain.org'
                        nginx['redirect_http_to_https'] = true
                        nginx['ssl_certificate'] = '/etc/letsencrypt/live/git.mydomain.org/fullchain.pem'
                        nginx['ssl_certificate_key'] = '/etc/letsencrypt/live/git.mydomain.org/privkey.pem'
        ports:
                - '192.168.100.3:80:80'
                - '192.168.100.3:443:443'
                - '192.168.100.3:22:22'
        volumes:
                - '/etc/letsencrypt:/etc/letsencrypt'
                - '/root/gitlab/gitlab/config:/etc/gitlab'
                - '/root/gitlab/gitlab/logs:/var/log/gitlab'
                - '/root/gitlab/gitlab/data:/var/opt/gitlab'
By David Buxton at 2018-02-24 11:47:51:

Yes, Gogs works well running on my VPS, behind Nginx with https. Although I use it only for private repos, so no public access at all. Easy to install, setup and upgrade, has the important features (including archive downloads for any commit).

https://gogs.io/

Written on 23 February 2018.
« Sorting out what exec does in Bourne shell pipelines
The question of what will be sending email spam over IPv6 »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Feb 23 00:59:49 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.