Fortiter Et Recte
I wrote a small Git hook which may be useful in helping OpenStack devs run tests (and any script they like) before a commit is made (see Superuser magazine article).
This way we can save everyone time in the review process by fixing simple issues before they break in the check-pipeline.
Installation is easy (see the GitHub page) and all prompts default to no, so that the dev can easily just hit Enter to skip and continue (but still be reminded).
I mirror a bunch of open source projects in a local GitLab instance which works well.
By default, GitLab only provides https and ssh access to repositories, which can be a pain for continuous integration (especially if you were to use self-signed certificates).
However, it’s relatively easy to configure your GitLab server to run a git daemon and provide read-only access to anyone on any repos that you choose.
Continue reading ‘Providing git:// (protocol) access to repos using GitLab’
There are several open source git repos that I mirror in order to provide local speedy access to. Pushing those to a local GitLab server also means people can easily fork them and carry on.
On the GitLab server I have a local posix mrmirror user who also owns a group called mirror in GitLab (this user is cannot be called “mirror” as the user and group would conflict in GitLab).
In mrmirror’s home directory there’s a ~/git/mirror directory which stores all the repos that I want to mirror. The mrmirror user also has a cronjob that runs every few hours to pull down any updates and push them to the appropriate project in the GitLab mirror group.
So for example, to mirror Linux, I first create a new project in the GitLab mirror group called linux (this would be accessed at something like https://gitlab/mirror/linux.git).
Then as the mrmirror user on GitLab I run a mirror clone:
[mrmirror@gitlab ~]$ cd ~/git/mirror
[mrmirror@gitlab mirror]$ git clone --mirror git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
When creating a shared git repository (perhaps on a central server) it’s good to use the –shared option:
git init --bare --shared
If you don’t, then you may find that repository permissions get clobbered each time a different person commits and no amount of umasks, chmods and sticky bits seem to help long term.
For your next shared repo that’s fine, but if you have an existing repository you can still fix this (assuming git is your group for write access):
ssh server
chown -Rf root:git /path/to/bare/git/repo
cd /path/to/bare/git/repo
git config core.sharedRepository group
find /path/to/bare/git/repo -type f | xargs chmod 664
find /path/to/bare/git/repo -type d | xargs chmod 775
find /path/to/bare/git/repo -type d | xargs chmod g+s
Enjoy some sanity!
Just a quick one for reference..
Deleting one or more local branches is trivial:
git branch --delete branch branch2
However if you want to delete regardless of the merge state:
git branch -D branch branch2
To delete a remote branch you need to push the delete:
git push remote --delete branch
The –delete option is newish, so if your git is old you can use the original syntax:
git push remote :branch
That’s all.
Matt just sent me an article on using Git with Vim, which looks pretty awesome.
Git.vim is a more comprehensive plugin that allows the user to perform a lot more Git operations from within the Vim environment.
Now if only the plugin for Eclipse was ready..
-c
At work we develop two open source Java applications, Xena and DPR, both of which we host on Sourceforge under CVS. I’ve been pushing to move away from CVS for quite some time now, but it hasn’t gained much traction. This has been mostly due to the lack of a decent Eclipse plugin and partly because of developer apathy. The other day I noticed that Sourceforge enabled support for Git, my favourite SCM system. Today I came across an article saying that they will now provide support for Bazaar and Mercurial also. Sweet.