Live data from Hacker News

How to Host Your Own Private Git Repositories

eklitzke.org

51–60 of 114 posts

Re: How to Host Your Own Private Git Repositories

#52
post #40
post #20

Earlier quoted context omitted.

What about Gitlab? Isn't that more popular than gitolite?

My impression is that GitLab is a web application. It does not really serve the same use case. Web access is good for open source projects where people may want to read the source without downloading the full repo. In the case of private projects, chances are that everyone involved will want to clone the whole repo anyways.

I don't mean to be pedantic, but Gitlab helps to host your own private git repos, which fits the title of the article. The article goes further, giving an example of how you can do some bare metal git hosting on a lightweight VM.

It's the same as running postfix/dovecot for configuring your own mail server (which could run on a lightweight VM), or using a turnkey solution such as Zimbra (which will include spam/virus filters, LDAP, calendars and much more).

Depends on your organisation: how often do you create accounts? who can do the sysadmin work? etc. I'm happy to sit back and let managers handle account management, and to be able to put Gitlab/Zimbra on a job description if we need to hire someone.

Re: How to Host Your Own Private Git Repositories

#55

Earlier quoted context omitted.

Hosting it yourself means that you don't have to muck with LFS. Want to check in a 7GB file? Go right ahead.

LFS is a tool to use to avoid checking in 7 gb files. If you want to weigh down your repo with binary bloat, don't configure your repo to use LFS.

Have you tried setting up LFS on your self-hosted ssh git repo?

Turns out LFS is designed to authenticate over https and doesn't work at all with ssh credentials out of the box because f* you.

I'm still hoping for a native git feature for large files, so the git-lfs crap can die in a fire.

Re: How to Host Your Own Private Git Repositories

#56
post #38

Earlier quoted context omitted.

But... you are using another online service to host the service yourself, no? And presumably they are also throwing in backups and redundancy of some sort... certainly it would take you a minute to set those things up, test them, monitor they are working... And isn't GitHub basically like everyone's resume these days? I don't know... at some point you sort of just have to trust someone... be it the hosting provider,…

It's especially sad because git is distributed and every time there's a GitHub outage I hear online some teams are blocked for the day. But everyone has the whole repo. You're not screwed like if your SVN or Perforce server goes down. Anyone could become the new "remote to push to / pull from" until the outage is resolved, or you could set up one of these bare repos somewhere pretty quick. When the outage is resolved…

IME, the popular-remote-service-is-down panics mostly seem to apply in web development world, where apparently any cool project must have an insane number of dependencies, no local failover or caching, and production build/test/deployment processes that are intimately connected to those dependencies that have no local equivalents. GitHub goes down, their entire CI and deployment system falls apart, and no-one has any idea what any of their fancy cloud-hosted doodads was actually doing at the underlying level of the Git repos or which files need to go where on the servers, so they don't know where to start with recovery...

Re: How to Host Your Own Private Git Repositories

#57
post #16

Earlier quoted context omitted.

gitolite has amazingly powerful access control, not just per-repo but per-branch or per-directory within a repo. It has very flexible self-service features, if you are OK with remote commands over ssh. Lots of nice scripting hooks. Gitolite home page: http://gitolite.com/gitolite/ I run a multi-tenant gitolite setup for the University of Cambridge: https://git.csx.cam.ac.uk/

Could you point to the documentation regarding per-directory access control? I find the documentation very difficult to navigate and I can't find anything relevant. I'm also not sure how it could work.

> I'm also not sure how it could work

Git repos can have an "update hook" that is executed during a push, after the new commits have been uploaded, but before the branch is updated to include the new commits. The hook can inspect the new commits, compare them to the old ones, and decide to reject the update. (It's a shell script, so every imaginable condition is possible.)

Re: How to Host Your Own Private Git Repositories

#58
If you want something light weight and "run and done" then check out GitBucket [0]. You only need the JVM & git installed. When you run the program it sets everything up. Very easy, clean interface, and simple to back up (I just snapshot the entier folder).

[0] - https://github.com/gitbucket/gitbucket

Re: How to Host Your Own Private Git Repositories

#59
post #21
post #2

I've been using Gogs happily for two years: https://gogs.io/docs/installation

I moved to https://gitea.io/ myself, largely because it seems to be more frequently updated these days.

definitely the best git repo for small teams! better than gitolite and manual hosting, lighter than gitlab, the best for me.

Re: How to Host Your Own Private Git Repositories

#60

Gitlab also can be run in your own server. It actually has an enterprise and an open source version. We use the open source one for a couple of years and it is really great - I recommend it with all my heart. It has great instructions for installing directly from source and you don't really need to be familiar with ruby to install it. It requires some standard components (web server, database) which should exist on a…

Gitlab is massive though. I think it's a great solution for teams on dedicated hardware, but if you need something quick, low-maintenance and lightweight Gitlab might be a bit overkill.
Post reply on HN