Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Host Your Own Private Git Repositories

eklitzke.org

Post reply on HN
Print view View original

31–40 of 114 posts

Re: How to Host Your Own Private Git Repositories

#31

Post by mnutt »

fanf2 wrote: post #16
uiri wrote: post #8

This is a good setup if you are the only one accessing the repo. If you need something a little bit more complex, I would highly recommend gitolite for managing repositories & users. Configuration is done via some INI/TOML-like files in a git repo. User public keys are stored in the same repo.

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/

I've run a ~30-user, ~1000-repo gitolite instance for a few years and while it has done its job admirably, there are a couple of things to know about:

It has a pretty clever config management system where the configuration is actually committed to a git repo. It's great if you're managing configuration by hand, but was difficult to automate via chef.

In order to let users create their own repos, we enabled "wild repos". It's as simple as a `git clone` with the desired repo name, which is great except that users often make typos and end up accidentally creating typo'd repos. The only person who can delete repos is the user who created them or the server admin deleting directories. Perhaps there are better features I should have used?

Re: How to Host Your Own Private Git Repositories

#32

Post by znpy »

Quick note: what this article doesn't explicitly says is that as long as you have a shell account somewhere with a decent amount of disk space, you can host or mirror all the repository you want.

If I may make a suggestion, I'd recommend the Super Dimensional Fortress Public Access UNIX System (https://sdf.org/).

They're NetBSD-based if I remember correctly, and for a low fee (36$/lifetime ARPA membership + 9$/quarter) you can host most of the things you would like to host.

And you don't have to do system maintenance.

Re: How to Host Your Own Private Git Repositories

#33

Post by JepZ »

uiri wrote: post #8

This is a good setup if you are the only one accessing the repo. If you need something a little bit more complex, I would highly recommend gitolite for managing repositories & users. Configuration is done via some INI/TOML-like files in a git repo. User public keys are stored in the same repo.

Hehe, I just found out that I am using gitolite since about six and a half years by now. It exists primarily for my personal endeavors, but at the moment it hosts about (small) 50 projects and 10 users.

While the hardware below had some major failures (2 SSDs died during that period) the gitolite always survived. I like it :-)

Re: How to Host Your Own Private Git Repositories

#35

Post by connorshea »

tajen wrote: post #27
fizixer wrote: post #20

Earlier quoted context omitted.

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

Tried Gitlab: It's incredibly messy. Haven't tried Gitolite. One of my criteria with git repos is the education of new programmers, and I believe starting with a clean, lean UI gave me an initial positive impression that Git was simple (surprising ey?). I won't advertise for the product of my company, but there are a few good UIs around there.

Why do you say it's messy? Would love to get feedback on improvements we can make :)

Re: How to Host Your Own Private Git Repositories

#36

Post by hathawsh »

marcinkuzminski wrote: post #34

RhodeCode is a good option for hosting, it has an advanced permission system, streaming push support and it scales well.

Thanks for the pointer. Your service looks interesting!

A little advice: it's probably best to post a disclaimer that you are the founder of RhodeCode whenever you post about it on HN. OTOH, you get credit for including that info in your HN profile.

Re: How to Host Your Own Private Git Repositories

#37

Post by fanf2 »

mnutt wrote: post #31
fanf2 wrote: 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/

I've run a ~30-user, ~1000-repo gitolite instance for a few years and while it has done its job admirably, there are a couple of things to know about: It has a pretty clever config management system where the configuration is actually committed to a git repo. It's great if you're managing configuration by hand, but was difficult to automate via chef. In order to let users create their own repos, we enabled "wild repo…

Wild repos are the self-service thing I referred to. You can turn off auto-create, so users have to explicitly run the `create` command - I did this, and typos have not been a problem for my users. The other niggle is the `perms` command is not as easy to use as I would like. But on the whole gitolite with wild repos has been really low-maintenance.

Re: How to Host Your Own Private Git Repositories

#38

Post by Jach »

dbg31415 wrote: post #30
RandomOpinion wrote: post #12

Earlier quoted context omitted.

> Why do this when http://bitbucket.com will host private git repos for free? Because you never know when one of these online services will suffer an outage, suffer a security breach that leasks your private repos or email & credentials, or even lose your data entirely. The fact that the service is free doesn't mean that it doesn't come without potential issues.

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 someone just pushes to the original and you're all fine.

Re: How to Host Your Own Private Git Repositories

#39

Post by voltagex_ »

znpy wrote: post #32

Quick note: what this article doesn't explicitly says is that as long as you have a shell account somewhere with a decent amount of disk space, you can host or mirror all the repository you want. If I may make a suggestion, I'd recommend the Super Dimensional Fortress Public Access UNIX System ( https://sdf.org/ ). They're NetBSD-based if I remember correctly, and for a low fee (36$/lifetime ARPA membership + 9$/quar…

I thought the ARPA membership was yearly?

Re: How to Host Your Own Private Git Repositories

#40

Post by uiri »

fizixer wrote: post #20
uiri wrote: post #8

This is a good setup if you are the only one accessing the repo. If you need something a little bit more complex, I would highly recommend gitolite for managing repositories & users. Configuration is done via some INI/TOML-like files in a git repo. User public keys are stored in the same repo.

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.
Post reply on HN