Creating Your Own Git Server | Hacker News Reader

Creating Your Own Git Server

gpanders.com

70 pointsgpanders34 comments

Git supports read-only, static HTTP cloning using nothing but "GET" requests on a bare Git repository. IOW, you don't need a CGI program or special request processor to serve a Git repository over HTTP. All you need to do is 1) make the bare Git repository visible under your web server's document root the same as-if you were serving .gif or .js files, and 2) maintain a special index after every commit using `git --bare update-server-info`, which I invoke from a post-receive hook.[1]

Because of this, you don't even need a CGI program for a web UI. Theoretically, it could all be done from client-side JavaScript. I've been wanting to write a PoC, but it's deep in my side-project backlog.

Why bother? Because a read-only, static Git mirror is more secure--there's no server software (other than a basic web server) that can be exploited. And nothing is always easier to maintain than something.

You still need SSH (or a git:// daemon) for write access, unless the entire environment is just for read-only cloning. But SSH access is presumably something already setup and used by the core contributors. (Probably shell access, too, but SSH logins can always be forced to invoke git.)

IMO, static, read-only HTTP cloning is a killer feature of Git which AFAIK cannot be matched by CVS, Subversion, Mercurial, or Fossil, at least not out-of-the-box.

[1] From a hook on the read-write, master repository outside the web server sandbox.

Something that would be a bit difficult when you only wanna use static files is code search. Would you need a backend for that or am I missing some obvious solution?

Once you clone the repository, you can search locally using Git Grep, Git ls-tree, etc.

Of course but that could be inconvenient in some situations. Like, when you just wanna show someone something in your code or when you wanna search across all repositories but don't wanna clone every single one manually again.

I recently set up Gitea on a VPS for my personal projects - I can highly recommend it. Setup was easy (for someone comfortable with linux configuration basics) and it's been an awesome improvement to my hobby development flow.

Seconded. I setup gitea on my server when Microsoft bought GitHub after comparing between gitlab, bitbucket, gogs, cgit, gitolite, and gitea. Gitea has the best community, features, and system requirements. Sad to say I still haven't moved my projects off of GitHub, but gitea setup wasn't the problem.

One thing I'd still like to see, and am thinking if I may (as a nobody with no connections) somehow be able to organise myself, is a global search. One of the main advantages of GitHub is discoverability, both as a project owner and as a project seeker. What if there was a server that distributed searches to the different self-hosted instances of gitea/gogs/gitlab/etc.? (Opt-in of course.)

The search would be distributed amongst all those setups which hopefully makes it light enough even though there will probably be a large volume, and this way people would have no reason to stay with a centralized company for git and bugtracker hosting. You could even have a client that connects to the instances individually, so even the search distribution server does not have to be centralized, you just need a DHT (ahem, I mean blockchain!) or some other central list of contributing nodes. And for very lightweight setups that still want to appear in search results, one could perhaps have different levels of results, from full code index to repository names and descriptions only.

You can get support for implementing something like this from NLnet. Either a federated version or a 'google for git' would fit the bill I imagine.

Or adding a code search feature to Software Heritage.

https://nlnet.nl/discovery/

That's a very interesting idea!

Edit: removed a part about ForgeFed which I thought was what I had in mind, and they do a lot of things that would be nice to have (slightly more convenient than just "login with GitHub")... except search which you can't simply work around by creating an account on each git server where you want to contribute. Not sure what part of their project is discovery and why NLnet granted them money under the "Next Generation Search and Discovery" fund which, from the description, is very clearly aimed at search.

I'm not an expert on the topic but that sounds like the Fediverse.

Would you know what protocol they use for search?

I see that things like the Plume blogging platform have a cross-instance search, but whenever I ctrl+f for search on any documentation page there's nothing. For example, it says the four protocols it uses are activitypub (link goes to the spec at W3; the whole spec never mentions the word search), webfinger (spec page, an RFC, also never mentions it), HTTP signatures (just for verification it seems), and nodeinfo ("not part of the federation itself, but that gives some metadata about each instance"). I've looked in more places but this was one of the more concrete examples of where there clearly is search but I can't find the code or protocol anywhere.

Edit: checked another; Peertube does not seem to search across instances.

In my opinion gitea is a good lightweight alternative to gitlab - easy to run, easy to maintain and pretty good for a private git server. Since it is written in go and consists of only ONE single binary, it is also easy to upgrade and it also performs well on smaller systems (e.g. Raspberry PI).

In professional environments with Jenkins and Sonarqube i would prefer gitlab though.

I actually looked at Gitea first but as far as I can tell they don't have a working Docker image for ARMv7 (I'm running on 32-bit Raspbian). I manage everything in a series of Docker compose files managed in version control, so not being able to use Docker was a deal breaker for me.

I'm keeping my eye on it though and if the situation ever changes, I will certainly take another look at it. Gitea seems like a great tool.

On one hand, yeah, I get it. I like using Docker for everything too.

On the other, installation is copying a single Go file to the desired location and running the configurator. Going from zero to fully set up and running took me about 15 minutes. At that point, Docker doesn't seem to offer a lot on top of that simplicity.

Totally agree, however the big draw for me is that with Docker/docker-compose I can keep all of the configuration in a version controlled repository along with all of the other apps/services I run on my little server. Of course it's possible to still do this and run it natively, but that's the reason I prefer a Docker solution.

There's a lot to be said for that, for sure! But I make up for a lot of lost ground on that by making a repo in /etc . I don't add everything to it, but I generally add files before I alter them so that I can roll back to the original state.

What's stopping you from using the ARMv6 version?

Nothing actually, in response to all of the mentions of Gitea in this thread I've since spun up the ARMv6 version myself and have been tinkering around with it!

I’ve also used this but on my home server as a way to have a local copy of my github/lab/private repos

I now use a personal Gogs instance, but I also want to give a shout-out to Klaus: it's something like Gitweb with a more Github-like UI. Klaus (like Github) shows you first and foremost the state of the tree with nicely rendered or syntax-highlighted file contents instead of (like Gitweb) focusing on the commit history first. It also has smart Git HTTP support out of the box without having to muck around in the web server config as described in this post.

The project is here https://github.com/jonashaag/klaus and you can see a preview of it here: http://klausdemo.lophus.org/

I've installed Gitlab in the earlier days, and that seems a lot easer than this guide. Gitlab comes with the web view included.

I agree with that. I did investigate a number of self-hosted alternatives to Github, but Gitlab was so much easier than any of them. My only complaint about Gitlab is that it uses a lot of CPU even when completely idle. But I was able to fix that easily by throttling it via the "cpulimit" utility.

My Fossil server on the other hand, has had no problems at all. Unless your project requires Git, you could save some pain by considering Fossil instead of Git.

I tried to install Gitlab a few years ago (many), and the installation was such a mess that I eventually just had to give up. Now with docker deployments, things are significantly easier.

The method in the post is pretty lightweight for getting a shared git server up and running without Docker. Most of the guide are extra tweaks for web-based comforts like converting README.md’s to HTML, etc.

All that said — I use a docker based install of Gitea for this. It doesn’t have as many features as Gitlab, but for an on-site option, it is pretty good. And I find the simplicity of it to be a feature.

If you run your own instance of Gitlab be sure to require login to view user profile pages. Otherwise you get spam users which will show up in Google results for the domain where you host your Gitlab instance.

You'll still get spam users but they won't show up in search.

In fact, you could probably set up a honey pot with user profile left publicly accessible. Then when the spammers show up, search Google for the email addys they use. Up should pop all the open source Gitlab instances which don't require a login to view user profiles. :)

Yeah - as someone who's ran their own git server back in the day with gitolite... 100% agree that GitLab is an easier/quicker solution.

Also it's fully featured and WAY simpler to setup on your run-of-the-mill VPS. Personally I have mine hosted at Linode at $25/mo with backups enabled + a $10/mo worker for simple Docker-based builds. This keeps all of my git repos private and 100% in my ownership which is how I prefer to work (sorry GitHub).

GitLab is amazing and I'm a huge advocate.

This is a very good write up. I've set up countless git servers in the day and have never really had the need for a UI, but I am intrigued by the description of gitweb.

On that note however, I would encourage anyone with a passing interest in an scm gui to check out fossil-scm. I'm helping a colleague with a project and that's what he is using. Really incredible piece of software with a lot of possibilities.

You're the third person in this comment section to mention Fossil. I'd never heard of it, but I'm definitely going to check it out.

You can also set up your own Fossil server by downloading a single executable and running it with a 2-line CGI script. Includes issues, wiki and forum.

https://www.fossil-scm.org/home/doc/trunk/www/server/

This is making me think about switching from gitlab. I don't like how complicated it is and it has way more features than I'll ever need. But I don't know how to use fossil. How does a git user become a fossil user and is it worth it just to switch webservers?

Late reply but...

> How does a git user become a fossil user

You just need to download the binary and start trying it out. Check out the Quick Start: https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki

A couple quick notes to help smooth the learning curve:

- There is no “staging” step in Fossil. Doing fossil commit immediately commits all changes in all tracked files into the repository. If you need to, you can specify which file or files you want to be included in the commit.

- There is no selective “patch committing” in Fossil (i.e., git add -p in Git), reportedly because it facilitates check-ins of untested code. So, if you’re in the habit of making unrelated edits to code…stop it!

> is it worth it just to switch webservers?

Depends on your priorities for each affected project. I already maintain a VPS as a web server for my various websites, so putting Fossil on it was an easy step. There is also Chiselapp.com if you don’t want to maintain your own web server.

There is also the fact that it’s just not git. Unless your project is extremely popular, you aren’t going to be getting “drive by pull requests” from anyone. The bar for participation in your project is going to be much higher since most people just aren’t familiar with Fossil. Depending on the project this could be a good thing or a bad thing.

I'm tremendously happy with Gitea - https://gitea.io/ - which in my opinion gets you as close as you can come to your own self-hosted version of GitHub, installed and ready to use in just minutes.

I did set up my own gitlab on a VPS. That ended up feeling quite fragile thought tbh. Even a working deploy (docker) seems to be spitting out a fair number of warnings. Jikes.

So new plan is google source repo + mirror somewhere safe for backup / non-google backup

I frequently install Gitea on Debian. Therefore I prepared an installer to do it:

https://github.com/emrahcom/emrah-buster-templates#eb-gitea

gitlab-ce is an apt install/upgrade and works like a charm.

I have a dual-core duo box running about 6 containers, including gitlab, and nginx as a reverse proxy.

I use letsencrypt for ssl, basic auth and duckdns to point cnames to my dhcp DSL.

I've been running my dev environment like this for several years. Works great.

you can also host your own Gitlab...

Reply on news.ycombinator.com