What is Reddit's opinion of
Gitolite?
From 3.5 billion Reddit comments
27 reviews of this app found across Reddit:
Small website/blog. Hosting some projects that happens to have a web frontend. A gitolite serv for personal non-public projects. And ssh for socks proxy when needed.
Also, you can find a bunch of ideas here: http://libreprojects.net/
You need to decide if you are going to host the git repositories in house (http://gitolite.com/gitolite/index.html for example) or any paid for service to host your repos for you.
For the build server again host it in house? or use a service which provides you this service (https://www.atlassian.com/ for example) as well as the hosting of your repos.
http://gitolite.com/gitolite/overview/#alternatives-to-gitolite
> gitlab, gogs, gitblit, and others
> There are several alternatives which offer a full web-based GUI, for administrators or users or both. They also offer a lot of enterprise features (for example LDAP integration), and social coding features (issue trackers, discussions, comments on code, pull requests, etc.)
These features are not part of Gitolite. Gitlab (since you mentioned that) can be self-hosted, so that might be an option for you, in case you need those features.
No remarks on fossil, unfortunately, but…
> I quickly realized that you pretty much have to have a PhD in git to admin a server repository.
If you just want to drop your repositories on a server with SSH access, without any additional features, just use
cd path/to/your/repository ssh $SERVER git init repositories/$REPOSITORY.git git remote add origin $SERVER:repositories/$REPOSITORY.git git push -u origin --all git push -u origin --tags
If you work completely alone, that's all that's necessary. Your server only needs git (and SSH) installed. If you want additional users without a full-blown web server, then gitolite might be of help.
Question - what problem do you have with your current setup that moving to something like GitLab / BitBucket would solve? Bosses don't care about features, they care about benefits. So all the cool features of a self-hosted setup like GitLab don't mean a thing to your boss. He wants to know what benefits he'll get if you make this change. If you can rephrase your answer along those lines, you might be able to convince him. So instead of looking at code review and pull requests as features, try to show him how he'll benefit if those are implemented.
But to be honest, with such a small team and the fact that no one seems to be collaborating on projects, I'd just stick with what you have or look at something like Gitolite, especially since you're implementing a separate issue tracking system already.
> Permissions, ACL. Those long forgoten features of ANY Unix.
Granted, ACL would mitigate that problem, as long as you properly take, e.g. remove accounts/users that don't work there any longer or moved to another department, you name it. Problem is, as an admin, you probably want to have a central place to control the ACLs. So you start to write a central configuration where removing dave is as simple as sed s/.*dave// or similar, maybe something along
repo foo RW = dave RW = alice R = bob
At that point, you've copied one feature of gitolite, and you still don't have git push --force protection. Furthermore, you cannot restrict/grant access on specific branches with ACLs, e.g. give bob only read access on master, but full access on bobs-awesome-features.
I'm all for using POSIX features, but the fine control of what's possible and what's not is out of reach for ACLs.
Personally I don't like web interfaces. I use gitolite (fully configurable by editing a file in a git repo), mailing lists, and cgit for showing the code to peasants.
Gitolite has facilities for rules-driven wild repository creation and serving, and supports admin-defined triggers and hooks.
Pros:
- works over ssh
- uses ssh keys for access/auth. If you want to give someone access to your repo, you only need their ssh pub key, and don't have to set up a local account
- runs under a non-root account (e.g. gitolite)
- easy to assign per user permissions and flexible (read only, commit, limit branch access, restrict destructive commits)
- available in repos for most major distros
- really light weight (basically a bunch of scripts and leverages existing git binary and ssh services)
- backup/restore is cake.
- backup: Tar up /var/lib/gitolite/ or wherever you set the repo to be
- restore: install gitolite, then restore /var/lib/gitolite/
Cons:
- if you're developing code on the server that hosts the Gitolite repos, you can check out code locally from the Gitolite repos, but you can't check in code. Have to check in/out via ssh on loopback if you want to use it locally on the server.
- Doesn't run on Windows (that I know of)
- No web interface (though cgit or something may work. Don't know, never tried)
- only uses ssh protocol. git:// based links don't work
Been using it for a few years, and unless I find a reason I need a web interface (have all the tools I need on my laptop), I don't see switching to anything else.
I also use it for a poor/lazy man's autodeployment. Install it on the server where I want to deploy my app, have a post-commit hook that runs a script that does a check out to /tmp/whatever, massages the permissions and whatnot, rsyncs the code to the production code location, then blows away /tmp/whatever.
> "$GIT_SSH" -V … outputs:
> plink: Release 0.63
Ah, so you're in the git-bash shell, not a Windows shell.
¿You've already gone over this stuff: gitolite.com/putty?
Gitolite is also another way of accomplishing the above without needing to create system users for everyone you want to grant access to the Git repos.
Gitolite also gives you some basic permissions (RW+/RW/R) that you can assign per-user on each repo.
This Digital Ocean tutorial will get you up and running with Gitolite in 10 minutes or less:
I would suggest taking it one step further and installing gitolite. This would give you the ability to share and manage git repositories remotely via git itself. This is the software kernel.org uses to manage the kernel sources.
Take a look at https://github.com/sitaramc/totport (documentation at http://gitolite.com/totport/)
It does a lot more and it's a bit more complicated though, to be honest.
The basic idea was inspired by something that Konstantin Ryabitsev (sysadmin for kernel.org) did some years ago -- before yubikeys and nitrokeys were widely used -- to incorporate 2FA into git push by kernel developers. I generalised it to allow use for pretty much any TCP-based service.
Most of the magic in this is from openssh, just to be clear.
Gitolite provides http and ssh based repo access managed by a text file, which is itself in a repo: just edit the file to add users, repos, or adjust permissions, then commit and push. It doesn't have a web frontend, but it plays nicely with cgit.
> Too bad GIT doesn't have read-only commits or some other way to back up without allowing others to use these private branches.
It does if you use right software to host it. Git itself is just repo format and basic protocol but it does allow adding checks like that extremely easy. The problem is none of big players (Gitlab, Github) embraced it.
Software like Gitolite is miles ahead in that (and was for years now), just it doesn't offer pretty frontend so it doesn't have that many users.
But it does allow you ACLs like "only NAME can write to repo/user/NAME" or "only @architects group can modify files in directory Z". It also allows for self service so you can create hierarchy, say users/NAME/REPO where users can push and create their own private repos.
> I realize GIT is distributed, so I could save my commits to any non-team repo, but I'm guessing 99% of corporate teams still use it similarly to SVN with the master server / client model.
It's not even a centralization issue, pushing to corp server means you also get your repos backed up by whatever your corp uses for it.
Doing the migration itself is easy. Any of your local repositories can become the "central" repository on AWS due to the nature of how Git works. Personally I find it odd to go from managed hosting to DIY hosting just because of how much work is actually involved when going DIY.
Has your boss laid out reasons for switching? If it's financial have you done a cost comparison of S3 to Bitbucket? Don't forget to include man hours setting up things in AWS and maintaining it.
Does your team use Bitbucket as more than just an online repository? Issue tracking, wiki, service integration? If you do are you okay with losing that?
Is anybody on your team experienced with AWS or system administration in general?
Do you have plans for keeping repositories secure? Gitolite can help here, but it's not turnkey.
> The process of synchronizing it now involves a pull request.
The GitHub implementation of this idea is also not a core Git concept.
> There were code review systems predating GitHub that used a similar model - but they were usually complex to set up and definitely not something you would just do on a whim. What GitHub did was make forking a repository a natural and obvious thing to do. It wasn't as much a technical breakthrough as a social networking innovation. Something on the level of concepts such as a "like" or a "tweet" that have become an integral part of our online existence.
It sounds like you already have an answer to your original question, or did I misunderstand it?
Before GitHub I guess people used the built-in idea of a pull request via email. Or they used something like gitolite to manage access to the central repo, so all contributors pushed to the same remote if they were given access by the project lead.
As the others have said, git isn't a deployment tool. You can build a deployment tool around git, though: http://gitolite.com/deploy.html
If you want to do it the way you are doing it, you shouldn't pull. What if there's a conflict? Nobody makes changes in production, you say, but what if someone force pushes or something? Instead, fetch and then reset --hard
Regarding permissions, git doesn't track them, except from the executable bit.
You haven't mentioned how the git repository(s) are hosted. If self-hosting, gitolite has good support for repository R/W access control based on ssh key.
Access to sensitive repositories is perhaps best managed via organizational policy.
> What happens if Composer fails or when it's slow as dirt?
Composer caches all installed versions locally. Run a composer install before deploying the files. I've also had a deployment git repository, with all the vendor files committed directly in the repository to speed up deployment and checkouts.
> How do you handle dev files you don't want in production like unit tests?
<code>composer install --no-dev</code>
> Do you really want your git commit history on a production sever?
Can use <code>git archive</code> to dump files , but having the full git checkout is handy as it allows switching tags rapidly (git checkout 1.5.3).
> How does data get migrated?
What data are you referring to?
You can ssh into maven from using PuTTY on windows or terminal on OSX/Linux - no VPN required either
From there, you can do all of your development, including run git. The ~/www directory is what is hosted on web.ics.purdue.edu/~username so if you need you can run git in that directory to pull changes.
If you want to have your master branch automagically updated to be put in your ~/www directory, you could write a cron script or put in commit hooks.
If you want to host a git server on ~~web.ics~~ maven, look into Gitolite
There some kind of way to lock files I think with git http://gitolite.com/gitolite/locking.html
There is also the possibility of MultiEdit.
Or is possible that we write a plugin that makes diff-friendly files of levels and bps?
Unfortunately, this would not remove deleted files. This was an option I considered and was discussed here: http://gitolite.com/deploy.html
As you can see the archive methods do have some shortfalls which make them less than ideal.
> Sorry, what? We ssh into the live server and pull from git. How are you supposed to do it?
With a deployment script. If you don't, you've got exactly the problem your experiencing -- permissions can be wrong; and worse you've given access to your development repository to the live server. If that server is ever compromised (and it's the one that faces the world, so is at risk) then the attacker gets access to your development history and your repository-hosting server.
I understand the attraction, git makes it very easy to update a working directory. But I'd lean more torwards git-archive limited to only what is needed for runtime and a deployment script that takes such an archive and puts it in the right place on the server, with the right permissions, applying deletions as well.
> Yes the .git directory is there. > > My entire development directory is not on the live server, never said it was.
These two statements are contradictory. If .gitis there, then your whole development directory (and its history) is there -- what else do you think is in .git?
Edit:
Here's a good article that covers some alternatives:
http://gitolite.com/deploy.html
I don't like it's chosen "favourite" of using git checkout because it leaves too much on the deployed machine, but the facts are good. (deploy to staging then rsync would be what I'd pick).
Edit2:
Another thing I meant to point out: deployment is of object code, not source code. Now, in some web development cases, the two are the same. But often they're not. Personally I deploy my python web projects as a set of .pyc files -- with no source left on the live server. It's not a huge protection, but it limits the information available to an attacker. Those .pyc files are absolute not stored in git, so how could one possibly deploy using git?
Indeed, it stores information about users and their repositories in text files, not necessarily one. It is possible to allow particular users or groups to create "wild repositories" without admin intervention. You can read more about it in upstream documentation.
If you need something really lightweight, gitolite works flawlessly. I'm using it since 2 years and I don't remember having any problems that couldn't be solved with RTFM.
Github cannot do this, unfortunately, though I really wish it could. For my own projects, I use Gitolite, an open-source repo hosting solution for Linux; it can do this. http://gitolite.com/gitolite/g2/bac.html
edit: The tradeoff is that gitolite is just repo hosting and access control. You don't get a fancy UI like Github or Gitlab. But unlike Gitlab, you can install it on your own server in about ten minutes. Gitlab's virtual appliances are easily deployable, but I've heard (only heard, never tried), that manually installing it on your own server can be a pain.
Plusses for Gitolite: Among other things, I run it on a Vultr high-storage VPS that is $5/mo and I get unlimited repos with all the access control I want. And I like the relative simplicity, honestly. Commandline is fine with me.
You can use the core.sharedRepository setting to tell Git to set the group read and write bits on all its internal files, so that multiple users on the same machine can modify the repository.
But this is a pretty poor solution.
You have to create a system user account for everyone who is to have access to the repository. You can lock down those accounts to only permit using Git using
git-shell, but that has no configuration to reject arbitrary repository paths.Creating system accounts requires root access to the server. That means you cannot delegate Git repo administration to anyone you do not trust with the keys to your entire empire.
Unix-level permissions are very limited. Just the fact that a file can only belong to one group makes it difficult to conveniently accommodate many use cases. I work in a team of 8 with about a dozen repos, and even we would be in trouble trying to stick to Unix permissions alone.
You have no control over Git-level concepts. You cannot restrict whether and what branches people can push to, you can only give them or not give them full access to a repository.
It’s really much cleaner to use gitolite, in spite of the added complexity you take on. And the docs make it look somewhat intimidating. But a basic config is very simple. Then you can give push access to the configuration to anyone you trust at that level without giving them any added system-level access whatsoever.
I’ve worked both ways under various circumstances, and for hosting central repositories there’s just no contest: gitolite is far less of a pain in the arse.