mkdir project.git; cd project.git
git init --bare
And to clone git clone user@example.com:project.git51–60 of 114 posts
mkdir project.git; cd project.git
git init --bare
And to clone git clone user@example.com:project.gitEarlier 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.
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.
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.
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.
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…
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.
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.)
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.
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…