5 ms·

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 managin

by uiri 10y ago

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.

fanf2 10y ago
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/ http://gitolite.com/gitolite/ I run a multi-tenant gitolite setup for the University of Cambridge: https://git.csx.cam.ac.uk/ https://git.csx.cam.ac.uk/
- mnutt 10y ago
  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?
  - fanf2 10y ago
    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.
- kingosticks 10y ago
  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.
  - majewsky 10y ago
    > 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.)
    - kingosticks 10y ago
      But that cannot prevent read access on a per-directory basis. I appreciate now that's not what you were referring to. I did find http://gitolite.com/gitolite/list-non-core/#partial-copy-selective-read-control-for-branches http://gitolite.com/gitolite/list-non-core/#partial-copy-sel... which seems to almost do what I wanted but that'll quickly explode to many copies of copies for any non-trivial situation. I know git can't do what I'm asking but every now and then something comes along and I gives me some hope before reality sets in.
      - fanf2 10y ago
        I do have a colleague using a partial copy, but if you need fine-grained read access control, you either need lots of git repos, or a different version control system.
rcarmo 10y ago
I second gitolite. It was great for preventing force push by newbies :)
fizixer 10y ago
What about Gitlab? Isn't that more popular than gitolite?
- mixedCase 10y ago
  I think the point here is providing a simple, lightweight solution. GitLab encompasses much, MUCH more than repository hosting.
- tajen 10y ago
  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.
  - connorshea 10y ago
    Why do you say it's messy? Would love to get feedback on improvements we can make :)
    - tajen 10y ago
      How many UI designers do you have per developer? Giving you feedback is a one-off; but the right density of UX designers in your teams and user interviews in your process will teach you much more.
- uiri 10y ago
  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.
  - mgbmtl 10y ago
    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.
atemerev 10y ago
...meanwhile, if your access control needs are less sophisticated, you can create the common group for all your git users, and use "git init --bare --shared=group" to set repository permissions correctly. (You'll have to create separate UNIX shell accounts for all your developers sharing a common group with this setup, and this may or may not be a good idea.)
JepZ 10y ago
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 :-)

by uiri 10y ago

fanf2 10y ago

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/ http://gitolite.com/gitolite/ I run a multi-tenant gitolite setup for the University of Cambridge: https://git.csx.cam.ac.uk/ https://git.csx.cam.ac.uk/

mnutt 10y ago
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?
- fanf2 10y ago
  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.
kingosticks 10y ago
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.
- majewsky 10y ago
  > 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.)
  - kingosticks 10y ago
    But that cannot prevent read access on a per-directory basis. I appreciate now that's not what you were referring to. I did find http://gitolite.com/gitolite/list-non-core/#partial-copy-selective-read-control-for-branches http://gitolite.com/gitolite/list-non-core/#partial-copy-sel... which seems to almost do what I wanted but that'll quickly explode to many copies of copies for any non-trivial situation. I know git can't do what I'm asking but every now and then something comes along and I gives me some hope before reality sets in.
    - fanf2 10y ago
      I do have a colleague using a partial copy, but if you need fine-grained read access control, you either need lots of git repos, or a different version control system.

rcarmo 10y ago

I second gitolite. It was great for preventing force push by newbies :)

fizixer 10y ago

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

mixedCase 10y ago
I think the point here is providing a simple, lightweight solution. GitLab encompasses much, MUCH more than repository hosting.
tajen 10y ago
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.
- connorshea 10y ago
  Why do you say it's messy? Would love to get feedback on improvements we can make :)
  - tajen 10y ago
    How many UI designers do you have per developer? Giving you feedback is a one-off; but the right density of UX designers in your teams and user interviews in your process will teach you much more.
uiri 10y ago
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.
- mgbmtl 10y ago
  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.

atemerev 10y ago

...meanwhile, if your access control needs are less sophisticated, you can create the common group for all your git users, and use "git init --bare --shared=group" to set repository permissions correctly. (You'll have to create separate UNIX shell accounts for all your developers sharing a common group with this setup, and this may or may not be a good idea.)

JepZ 10y ago

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 :-)