MAC OS X, Linux, Windows and other IT Tips and Tricks

16 Oct 15 Installing a newer git version in Debian/Ubuntu

In many cases where Git is involved it’s possible ethat your distribution doesn’t offer the version of git that is appropriate to the software you want to run. In this case you can install from sources.
Here is one method fro example to install the version 2.4.3.

Remove packaged Git
apt-get remove git
If you have other packages that depend on git , apt will most probably prevent the de-installation of git. In that case you can run the following command:
dpkg --force-depends -r git
Install dependencies
apt-get install -y libcurl4-openssl-dev libexpat1-dev gettext libz-dev libssl-dev build-essential
Download and compile from source
cd /tmp
curl -L --progress | tar xz
cd git-2.4.3/
make prefix=/usr/local all

Install into /usr/bin
make prefix=/usr/local install
Check the git version
git --version

05 Jun 15 Installing GitLab (MySQL based) on Ubuntu 14.04.2 LTS Server

Note: Instructions based on but have been modified in a few places to make it work with mySQL:

Extra related Info:


adduser --disabled-login --gecos 'GitLab' git
apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server redis-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate python-docutils pkg-config cmake nodejs
apt-get install postfix git libpq-dev sudo nodejs

(Select ‘Internet site’ for postfix)
# Make sure ruby is de-installed (we need the manually installed version >2.0 for Gitlab)
apt-get remove ruby
mkdir /tmp/ruby && cd /tmp/ruby
tar xvzf ruby-2.1.2.tar.gz
cd ruby-2.1.2
./configure --without-X11 --disable-install-rdoc --prefix=/usr/local
make && make install

Installing Mysql Server

Notes: These instructions are based on
The above site mentions the Mysql Bug ( but it has been fixed in MySQL Ver. 5.5.24
Install the database packages
apt-get install -y mysql-server mysql-client libmysqlclient-dev
Ensure you have MySQL version 5.5.24 or later
mysql --version
# Pick a MySQL root password (can be anything), type it and press enter
# Retype the MySQL root password and press enter
# Secure your installation (not really needed in this set-up if the server for for internal use)
# Login to MySQL
mysql -u root -p
# Type the MySQL root password

# Create a user for GitLab
Note: do not type the ‘mysql>’, this is part of the prompt
# change $password in the command below to a real password you pick
mysql> CREATE USER 'git'@'localhost' IDENTIFIED BY '$password';
# Ensure you can use the InnoDB engine which is necessary to support long indexes
# If this fails, check your MySQL config files (e.g. `/etc/mysql/*.cnf`, `/etc/mysql/conf.d/*`) for the setting “innodb = off”
mysql> SET storage_engine=INNODB;
# Create the GitLab production database
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
# Grant the GitLab user necessary permissions on the database
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, LOCK TABLES ON `gitlabhq_production`.* TO 'git'@'localhost';
# Quit the database session
mysql> \q
# Try connecting to the new database with the new user
sudo -u git -H mysql -u git -p -D gitlabhq_production
# Type the password you replaced $password with earlier
# You should now see a ‘mysql>’ prompt
# Quit the database session
mysql> \q

Installing REDIS

apt-get install redis-server
# Configure redis to use sockets
cp /etc/redis/redis.conf /etc/redis/redis.conf.orig
# Disable Redis listening on TCP by setting ‘port’ to 0
sed 's/^port .*/port 0/' /etc/redis/redis.conf.orig | sudo tee /etc/redis/redis.conf
# Enable Redis socket for default Debian / Ubuntu path
echo 'unixsocket /var/run/redis/redis.sock' | sudo tee -a /etc/redis/redis.conf
# Grant permission to the socket to all members of the redis group
echo 'unixsocketperm 770' | tee -a /etc/redis/redis.conf
# Create the directory which contains the socket
mkdir /var/run/redis
chown redis:redis /var/run/redis
chmod 755 /var/run/redis

# Persist the directory which contains the socket, if applicable
if [ -d /etc/tmpfiles.d ]; then echo 'd /var/run/redis 0755 redis redis 10d -' | tee -a /etc/tmpfiles.d/redis.conf ; fi
# Activate the changes to redis.conf
service redis-server restart
# Add git to the redis group
usermod -aG redis git

Installing GitLAB

cd /home/git
git clone -b 7-11-stable gitlab

# Give the ownership to git user of transferred repository
chown -R git: /home/git/gitlab
cd /home/git/gitlab

# Make sure GitLab can write to the log/ and tmp/ directories
chmod -R u+rwX {log,tmp,tmp/pids,tmp/sockets,public/uploads}
chown -R git log/
chown -R git tmp/

# Create the GitLab config file:
sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml
nano config/gitlab.yml

# You need to change the value of host to the fully-qualified domain of your server.
# Also set the email_from and support_email to the email addresses intended for GitLab.
# Content of /home/git/gitlab/config/gitlab.yml
production: &base
port: 443
https: true

# Make sure GitLab can write to the log/ and tmp/ directories
chown -R git {log,tmp}
sudo chmod -R u+rwX,go-w log/
sudo chmod -R u+rwX tmp/

# Create directory for satellites
sudo -u git -H mkdir /home/git/gitlab-satellites
chmod u+rwx,g=rx,o-rwx /home/git/gitlab-satellites

# Make sure GitLab can write to the tmp/pids/ and tmp/sockets/ directories
chmod -R u+rwX tmp/pids/
chmod -R u+rwX tmp/sockets/

# Make sure GitLab can write to the public/uploads/ directory
chmod -R u+rwX public/uploads

Configure Unicorn

# Copy the example Unicorn config
sudo -u git -H cp config/unicorn.rb.example config/unicorn.rb
# Find number of CPU cores in order to configure Redis properly
# Enable cluster mode if you expect to have a high load instance
# Ex. change amount of workers to 3 for 2GB RAM server
# Set the number of workers to at least the number of cores
nano config/unicorn.rb
# Copy the example Rack attack config
sudo -u git -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb
# Configure Git global settings for git user, used when editing via web editor
sudo -u git -H git config --global core.autocrlf input
# Configure Redis connection settings
sudo -u git -H cp config/resque.yml.example config/resque.yml
# Change the Redis socket path if you are not using the default Debian / Ubuntu configuration
nano config/resque.yml

Important Note:
Make sure to edit both gitlab.yml and unicorn.rb to match your setup.

Note: If you want to use HTTPS, see Using the following HTTPS for the additional steps.
(Also see

To use GitLab with HTTPS:

1. In gitlab.yml:
Set the port option in section 1 to 443.
Set the https option in section 1 to true.
2. In the config.yml of gitlab-shell:
Set gitlab_url option to the HTTPS endpoint of GitLab (e.g.
Set the certificates using either the ca_file or ca_path option.
3. Alternatively use the gitlab-ssl Nginx example config instead of the gitlab config.
Update ssl_certificate and ssl_certificate_key.
Review the configuration file and consider applying other security and performance enhancing features.

Configure the Database connection:

# Create the config/database.yml file
cp config/database.yml.mysql config/database.yml
# Adapt the file config/database.yml to configure the Database parameters
# Normally only the git user password and host and port need to be changed/added as follows
nano config/database.yml
adapter: mysql2
encoding: utf8
reconnect: false
database: gitlabhq_production
pool: 10
username: git
password: "secure password"
host: localhost
port: 3306
# socket: /tmp/mysql.sock

# Make sure that config/database.yml is readable to git only:
chown git: config/database.yml
sudo -u git -H chmod o-rwx config/database.yml

# Install the gems:
Note : Under ‘N‘ in ‘-jN‘ is the number of CPUs in your server. This helps to accelerate the process.
su -
gem install bundler
su - git
cd ~/gitlab
bundle install -jN --deployment --without development test postgres aws kerberos

Install GitLab Shell

#Install GitLab shell, which is an SSH access and repository management software for GitLab:
bundle exec rake gitlab:shell:install[v1.9.4] REDIS_URL=redis://localhost:6379 RAILS_ENV=production
# Edit the GitLab shell configuration file and make sure of the following content
# and adapt to your needs and environment (especially gitlab_url: the rest should be left as is but just check.)
nano /home/git/gitlab-shell/config.yml
user: git
self_signed_cert: false
repos_path: "/home/git/repositories/"
auth_file: "/home/git/.ssh/authorized_keys"
bin: "/usr/bin/redis-cli"
namespace: resque:gitlab
socket: "/var/run/redis/redis.sock"
log_level: INFO
audit_usernames: false

# Initialize database and activate advanced features:
Run the following 2 commands as git user:

su - git
cd /home/git/gitlab
bundle exec rake gitlab:setup RAILS_ENV=production

# The command will display the following message
This will create the necessary database tables and seed the database.
You will lose any previous data stored in the database.
Do you want to continue (yes/no)?

# Type yes and press Enter to continue.
# It is important to remember the last 3 lines (Administrator account created:)

# Install the init script and make GitLab start on boot:
sudo cp /home/git/gitlab/lib/support/init.d/gitlab /etc/init.d/gitlab
sudo chmod 755 /etc/init.d/gitlab

# Make GitLab start on boot:
sudo update-rc.d gitlab defaults 21
# Set up logrotate:
sudo cp /home/git/gitlab/lib/support/logrotate/gitlab /etc/logrotate.d/gitlab
# Check application status:
cd /home/git/gitlab
bundle exec rake gitlab:env:info RAILS_ENV=production

# The following information should show up
System information
System information
System: Ubuntu 14.04
Current User: git
Using RVM: no
Ruby Version: 2.1.6p336
Gem Version:
Bundler Version: 1.10.2
Rake Version: 10.4.2
Sidekiq Version: 3.3.0
GitLab information
Version: 7.11.4
Revision: b725318
Directory: /home/git/gitlab
DB Adapter: mysql2
SSH Clone URL:
Using LDAP: yes
Using Omniauth: no
GitLab Shell
Version: 2.6.3
Repositories: /home/git/repositories/
Hooks: /home/git/gitlab-shell/hooks/
Git: /usr/bin/git

# Compile assets:
bundle exec rake assets:precompile RAILS_ENV=production
# Configure Git global settings for the git user:
git config --global "GitLab"
git config --global ""
git config --global core.autocrlf input

Set the above value for ‘’ according to what is set in config/gitlab.yml

Login back as root superuser
# Start GitLab:
service gitlab start

INSTALL NginX for Gitlab

# Install Nginx if you haven’t installed it:
apt-get install nginx
# Copy the sample site config:
cp /home/git/gitlab/lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
# Install the web certificates in a /etc/nginx/certs/
# Combine the certificate and CA together in one file
cat /etc/nginx/certs/wildcard.server.com_CRT.pem /etc/nginx/certs/Thawte_2010.02.08-2020.02.07_CA.pem > /etc/nginx/certs/wildcard.server.com_CRT_CA.pem
# Open the config file(/etc/nginx/sites-available/gitlab) and adapt the following configuration entries
listen *:443 ssl;
ssl_certificate /etc/nginx/certs/wildcard.server.com_CRT_CA.pem;
ssl_certificate_key /etc/nginx/certs/wildcard.server.com_KEY.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!DSS:!DES:!SSLv2:!MD5;
gzip off;

# Deactivate the default configuration
rm /etc/nginx/sites-enabled/default
# Activate the site and restart Nginx to take effect
ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
service nginx restart

# If Nginx failed to start with the following message
Restarting nginx: nginx: [emerg] could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32
# Open /etc/nginx/nginx.conf and uncomment the following line
server_names_hash_bucket_size 64;
Then restart Nginx.

Open GitLab on Your Browser

# Double check the application status:
su - git
cd ~/gitlab
bundle exec rake gitlab:check RAILS_ENV=production

If most of the items are green and some are purple (which is okay since you don’t have any git project yet), then you have successfully installing GitLab.

# First initialization of Gitlab and Password change
# Type the following address in browser:
# First thing: Change the password of administrator (
# Then confirm the new password by entering it twice.
# re-login and Tada !!! BobsYourUncle 🙂

Troubleshooting Gitlab

# Self check command:
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true

# Check the general configuration of GitLab:
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

# Check/precompile if all assets were properly pre-compiled or for assets access errors:
cd /home/git/gitlab
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production

# INFO: Gitlab Logs are found in:

LDS-LDAP Authentication

In order to enable the LDS-LDAP authentication make the following changes:
Edit the file /home/git/gitlab/config/gitlab.yml and modify the section ldap: as follows:
enabled: true
host: ''
port: 636
uid: 'userPrincipalName'
method: 'ssl'
bind_dn: 'lds-auth'
password: '{password}'
active_directory: true
allow_username_or_email_login: false
base: 'DC=CORP,DC=ad,DC=server,DC=com'
user_filter: ''

#Restart gitlab daemon
service gitlab restart
#Check the LDAP authentication mechanism with the following command:
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production

Checking LDAP ...
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: CN=............
If the first 100 users DN: data is shown then the LSD-LDAP for gitlab is working

Instructions on how to create a new user on GitLab

– Login with your company login in LDAP Authentication at The new user will automatically be created in GitLab system.
– Add your public SSH key in the page
– Remember your username in the page: under ‘Change Username’ field.
– Remember your email in the page: under ‘Email’ field.
– For linux users using the git command line, run the following commands(assuming that you want your git workspace in ~/gitlab/ directory)
Note: Make sure you replace the above remembered username and email below shown as <USERNAME> and <EMAIL>
– Initializing a workspace for gitlab repositories
mkdir ~/gitlab/ ; cd ~/gitlab/
git config --global <USERNAME>

– Then verify that you have the correct username:
git config --global
– To set your email address, type the following command:
git config --global <EMAIL>
– To verify that you entered your email correctly, type:
git config --global
git config --global --list

– Change to simple push default format
git config --global push.default simple
– Create a new repository as new project in the gitlab web interface run the following command to clone the repository in your local git workspace(assuming here ~/gitlab/)
cd ~/gitlab/

– To commit the first file(special push case for the first file):
echo "first file content" > first_file
git add first_file
git commit -m 'test commit 1'
git push origin master

– Now all the other files will be pushed normally as follows:
echo "second file content" > second_file
git add second_file
git commit -m 'test commit 2'
git push

09 Dec 14 Installing GITLAB-Omnibus in Debian Wheezy


The instructions here have been based on the site:
I did what is shown there but it didn’t work immediately. I had to do the following tweaks and then it all worked fine so far.
IMPORTANT: In order to stay updated see the last par at the end of this article for instruction son how to Upgrade.

In these examples I use the domain Replace it with your own domain.


Run the following commands to install GitLab.
apt-get install postfix
wget --no-check-certificate
dpkg -i
nano /etc/gitlab/gitlab.rb

# Check and change the external_url to the address your users will type in their browser
external_url ''
gitlab_rails['gitlab_email_from'] = ''

Create the following certificate files:

Start the last installation procedure:
gitlab-ctl reconfigure
Here is what you see in logs if you don’t make the following changes:
WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1'
to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

So, edit /etc/sysctl.conf and add:vm.overcommit_memory = 1
Run:sysctl vm.overcommit_memory=1
Make sure your DNS settings of are pointing to the IP of this host. Login at :
Login: root
Passowrd: 5iveL!fe

– Change password of Administrator(root)
– Create new user(s)
…. and you’re up and running GitLab.
Some extra information regarding the administration of GitLab:

The gitlab-ctl Command:
Info: (/usr/bin/gitlab-ctl -> /opt/gitlab/bin/gitlab-ctl)
This command should be run as root or under sudo:
gitlab-ctl SubCommand [ProcessName]
SubCommand Description:
cleanse Delete *all* gitlab data, and start from scratch.
deploy-page Put up the deploy page
graceful-kill Attempt a graceful stop, then SIGKILL the entire process group.
help Print this help message.
hup Send the services a HUP.
int Send the services an INT.
kill Send the services a KILL.
once Start the services if they are down. Do not restart them if they stop.
reconfigure Reconfigure the application.
restart Stop the services if they are running, then start them again.
service-list List all the services (enabled services appear with a *.)
show-config Show the configuration that would be generated by reconfigure.
start Start services if they are down, and restart them if they stop.
status Show the status of all the services.
stop Stop the services, and do not restart them.
tail Watch the service logs of all enabled services.
term Send the services a TERM.
uninstall Kill all processes and uninstall the process supervisor (data will be preserved).

ProcessName valid values:

For more information on GitLab see:
Use the manual mode to install GitLab shown at:
Use LDAP to login:
Or used Windows ADS to login:
The some extra info/troubleshooting:
And the support Forum:!forum/gitlabhq



I can push by clone project using ssh, but it doesn’t work when I clone project with https. it shows message error as below.
server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Solution 1:
You need to check the web certificate used for your gitLab server, and add it to your (git_intallation_folder)/bin/curl-ca-bundle.crt.
To get that certificate (that you would need to ad to your curl-ca-bundle.crt file), run:
echo -n | openssl s_client -showcerts -connect yourGitLabServer:YourHttpGilabPort 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
To check the CA (Certificate Authority issuer), run:
echo -n | openssl s_client -showcerts -connect yourGitLabServer:YourHttpGilabPort 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'| openssl x509 -noout -text | grep "CA Issuers" | head -1
Findekano adds in the comments: to identify the location of curl-ca-bundle.crt, you could use the command:
curl-config --ca

Solution 2 (not really recommended for production servers):
To check if at least the clone works without checking said certificate, you can set:
git config --global http.sslverify false

But that would be for testing only, as illustrated in “SSL works with browser, wget, and curl, but fails with git”.

Creating a new repository/project with Linux clients

Example: creating the project gitrepo1

Git global setup
git config --global "Administrator"
git config --global ""

Create a new repository
mkdir gitrepo1
cd gitrepo1
git init
git add
git commit -m "first commit"
git remote add origin
git push -u origin master

Push an existing Git repository
cd existing_git_repo
git remote add origin
git push -u origin master

Note: The ownername is the username of the person who created the project. If that username has already a Dot ‘.’ in it, it should be replaced by a Dash’-‘ in the above commands.

Instructions on how to create a new user on GitLab

– Login with your company login in LDAP Authentication at The new user will automatically be created in GitLab system.
– Add your public SSH key in the page
– Remember your username in the page: under ‘Change Username’ field.
– Remember your email in the page: under ‘Email’ field.
– For linux users using the git command line, run the following commands(assuming that you want your git workspace in ~/gitlab/ directory)
Note: Make sure you replace the above remembered username and email below shown as <USERNAME> and <EMAIL>
– Initializing a workspace for gitlab repositories
mkdir ~/gitlab/ ; cd ~/gitlab/
git config --global <USERNAME>

– Then verify that you have the correct username:
git config --global
– To set your email address, type the following command:
git config --global <EMAIL>
– To verify that you entered your email correctly, type:
git config --global
git config --global --list

– Change to simple push default format
git config --global push.default simple
– Create a new repository as new project in the gitlab web interface run the following command to clone the repository in your local git workspace(assuming here ~/gitlab/)
cd ~/gitlab/

– To commit the first file(special push case for the first file):
echo "first file content" > first_file
git add first_file
git commit -m 'test commit 1'
git push origin master

– Now all the other files will be pushed normally as follows:
echo "second file content" > second_file
git add second_file
git commit -m 'test commit 2'
git push

Upgrading GitLab Omnibus

Here are the instructions on how to upgrade GitLab Omnibus Community Edition.
curl -s | bash
apt-get install gitlab-ce=7.14.1-ce.0

And let the screen roll while watching for errors. 🙂

15 Aug 13 Installation of GIT, Gitolite and Gitweb in Debian Squeeze

Note: This tutorial is based on this very good site, thanks for the work:


This is a simple and step by step tutorial on how to install GIT server and Gitolite in Debian Squeeze.Since GIT has no authentication/authrization methods on its own Gitolite does fill in. Gitolite allows to control new creation of all new GIT repositories as well as who is allowed to work with which repository. All done via configuration files in a gitolite-admin repository which gets pulled from the master GIT server by the Gitolite admin user, modified and pushed back. Then the magic happens immediately at the server side.


========== In GIT server =========
Install git and gitolite
apt-get update
apt-get install git-core python-setuptools gitolite

Setup the gitolite temp password
passwd gitolite
Create the .ssh directory to contain the remote client’s public keys
su - gitolite
mkdir $HOME/.ssh/

========= in your desktop Linux as gitolite user ==================

Create the gitadmin user as git administrator
(press the {Enter} key as answer to every question)
useradd -m gitadmin
su - gitadmin
ssh-keygen -t rsa

Create the GIT repositories base directory
mkdir ~/gitrepos
Transfer the git administrator’s public key to gitolite ~/.ssh/ directory in server
cat ~/.ssh/ | ssh 'cat > ~/.ssh/'
================ Back in GIT server as gitolite user ===============
Setup gitolite with the gitadmin pub key
gl-setup $HOME/.ssh/
================ in your desktop linux as gitadmin user ===============
Clone the gitolite control repo into your local work space
cd ~/repositories
git clone ssh://

Some descriptitons of the configuration files:
~/gitrepos/gitolite-admin/conf/gitolite.conf: file and you will add users, privileges and projects/repos here
~/gitrepos/gitolite-admin/conf/keydir/: directory that contains the ssh public keys files of git users

IMPORTANT: Make sure the filename of ssh key matches the user in gitolite.conf without the ‘.pub’
eg. For user ‘martin’ you would have your ssh key file in keydir/ and in gitolite.conf you have the following:
repo gitolite-admin
RW+ = martin

Adding the first normal git user called ‘martin’

================ IN martins’s desktop ===============
Transfer martin’s ssh public key to the GIT server
cat ~/.ssh/ | ssh 'cat > ~/gitrepos/gitolite-admin/keydir/'

================ Back to the gitadmin user’s desktop ===============
Configuring gitolite to allow martin to be able to read/write/push in testrepo1 repo
vim ~/gitrepos/gitolite-admin/conf/gitolite.conf
repo gitolite-admin
RW+ = gitadmin
repo testrepo1
RW+ = martin
repo public-repo
RW+ = @all

This above configuration means:(RW+=Read Write Push)
gitadmin can RW+ on gitolite-admin repo
martin can RW+ on testrepo1 repo
everybody can RW+ on public-repo

Update the new config to the master git server
cd ~/gitrepos/gitolite-admin/
git add keydir/*
git commit -am "added martin access to testrepo1 repo"
git push

NOTE: with the ‘push’ gitolite on the git server will create the missing repositories automatically in the git server and assign their proper access rights. Never any need to go on the git server to create new repos.

Working on the testrepo1 repo from martin’s desktop

================ In martin’s desktop as martin user ===============
mkdir gitrepos
cd gitrepos/
git clone ssh://

Response should be:
Cloning into testrepo1...
warning: You appear to have cloned an empty repository.

Now make changes in the repo
cd testrepo1
echo "content1" >testfile1.txt

Commit the changes to the server
git add testfile1.txt
git commit -am 'First commit to repo'

NOTE: No need to worry about the lots of warning messages
Simply note the Committer line message:
Committer: martin <martin@laptop.local>

To illiminate those messages do the following commands:
git config --global martin
git config --global martin@laptop.local

The first time you make a push to an empty repository it should be done this way
git push origin master
You should get the follwoing similar result:
Counting objects: 3, done.
Writing objects: 100% (3/3), 229 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://
* [new branch] master -> master

From now on the repository committing and push commands will done as normal. Example:
echo "second file" > testfile2.txt
git add testfile2.txt
git commit -am 'Second commit to repo'
git push

Result should be:
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 290 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://
3aa8b8f..5472dfc master -> master


This part of the tutorial is an identical extract of the following article. Thanks for the good work:


Do NOT add new repos or users manually on the server. Gitolite users, repos, and access rules are maintained by making changes to a special repo called ‘gitolite-admin’ and pushing those changes to the server.

To administer your gitolite installation, start by doing this on your workstation (if you have not already done so):
git clone ssh://

**NOTE**: if you are asked for a password, something has gone wrong with the initalization of gitolite with the admin’s public key.

Now if you ‘cd gitolite-admin’, you will see two subdirectories in it: conf and keydir.

To add new users alice, bob, and carol, obtain their public keys and add them to keydir directory as,, and respectively. Make sue the name of the user used in the configuration file is the same as the key filename (without the .pub)

To add a new repo ‘foo’ and give different levels of access to these users, edit the file ‘conf/gitolite.conf’ and add lines like this:
repo foo
RW+ = alice
RW = bob
R = carol

See the ‘ACCESS RULES’ section later for more details. Once you have made these changes, do something like this:
cd ~/gitrepos/gitolite-admin/
git add keydir/*
git commit -m 'added foo, gave access to alice, bob, carol'
git push

When the push completes, gitolite will add the new users to ~/.ssh/authorized_keys on the server, as well as create a new, empty, repo called ‘foo’.


Once a user has sent you their public key and you have added them as specified above and given them access, you have to tell them what URL to access their repos at. This is usually ‘git clone git@host:reponame’; see man git-clone for other forms.

**NOTE**: again, if they are asked for a password, something is wrong.

If they need to know what repos they have access to, they just have to run ‘ssh git@host info’; see ‘COMMANDS’ section later for more on this.


The basic syntax of the conf file is very simple.

* Everything is space separated; there are no commas, semicolons, etc., in the syntax.
* Comments are in the usual perl/shell style.(the ‘#’)
* User and repo names are as simple as possible; they must start with an alphanumeric, but after that they can also contain ‘.‘, ‘_‘, or ‘‘.

Usernames can optionally be followed by an ‘@’ and a domainname containing at least one .; this allows you to use an email address as someone’s username.

Reponames can contain / characters; this allows you to put your repos in a tree-structure for convenience.

* There are no continuation lines.


This section is mostly ‘by example’.

Gitolite’s access rules are very powerful. The simplest use was already shown above. Here is a slightly more detailed example:
repo foo
RW+ = alice
- master = bob
- refs/tags/v[0-9] = bob
RW = bob
RW refs/tags/v[0-9] = carol
R = dave

For clones and fetches, as long as the user is listed with an R, RW or RW+ in at least one rule, he is allowed to read the repo.
For pushes, rules are processed in sequence until a rule is found where the user, the permission (see note 1), and the refex (note 2) *all* match. At that point, if the permission on the matched rule was ‘‘, the push is denied, otherwise it is allowed. If no rule matches, the push is denied.

Note 1: permission matching:

* a permission of RW matches only a fast-forward push or create
* a permission of RW+ matches any type of push
* a permission of ‘-‘ matches any type of push

Note 2: refex matching:
(refex = optional regex to match the ref being pushed)

* an empty refex is treated as ‘refs/.*
* a refex that does not start with ‘refs/’ is prefixed with ‘refs/heads/’
* finally, a ‘^’ is prefixed
* the ref being pushed is matched against this resulting refex

With all that background, here’s what the example rules say:

* alice can do anything to any branch or tag — create, push, delete, rewind/overwrite etc.
* bob can create or fast-forward push any branch whose name does not start with ‘master’ and create any tag whose name does not start with ‘v‘+digit.
* carol can create tags whose names start with ‘v‘+digit.
* dave can clone/fetch.


Gitolite allows you to group users or repos for convenience. Here’s an example that creates two groups of users:
@staff = alice bob carol
@interns = ashok
repo secret
RW = @staff
repo foss
RW+ = @staff
RW = @interns

Group lists accumulate. The following two lines have the same effect as the earlier definition of @staff above:
@staff = alice bob
@staff = carol

You can also use group names in other group names:
@all-devs = @staff @interns

Finally, @all is a special group name that is often convenient to use if you really mean ‘all repos‘ or ‘all users‘.


Users can run certain commands remotely, using ssh. For example:
ssh git@host help
prints a list of available commands.

The most commonly used command is ‘info’. All commands respond to a single argument of ‘-h’ with suitable information. If you have shell on the server, you have a lot more commands available to you; try running ‘gitolite help’.


Some of the instructions below may require you to edit the rc file (~/.gitolite.rc on the server).

The rc file is perl code, but you do NOT need to know perl to edit it. Just mind the commas, use single quotes unless you know what you’re doing, and make sure the brackets and braces stay matched up.


Gitolite lets you set git-config values for individual repos without having to log on to the server and run ‘git config’ commands:
repo foo
config hooks.mailinglist = foo-commits@example.tld
config hooks.emailprefix = '[foo] '
config = ''
config foo.baz =

The last two syntaxes shown above are the *only* way to *delete* a config variable once you have added it. Merely removing it from the conf file will *not* delete it from the repo.git/config file.

Some git-config keys allow arbitrary code to be run on the server.

If all of your gitolite admins already have shell access to the server account hosting it, you can edit the rc file (~/.gitolite.rc) on the server, and change the GIT_CONFIG_KEYS line to look like this:
Otherwise, give it a space-separated list of regular expressions that define what git-config keys are allowed. For example, this one allows only variables whose names start with ‘gitweb’ or with ‘gc’ to be defined:
GIT_CONFIG_KEYS => 'gitweb\..* gc\..*',


Gitolite creates the ‘git-daemon-export-ok’ file for any repo that is readable by a special user called ‘daemon’, like so:
repo foo
R = daemon


Any repo that is readable by a special user called ‘gitweb’ will be added to the projects.list file.
repo foo
R = gitweb

Or you can set one or more of the following config variables instead:
repo foo
config gitweb.owner = some person's name
config gitweb.description = some description
config gitweb.category = some category

You will probably need to change the UMASK in the rc file from the default (0077) to 0027 and add whatever user your gitweb is running as to the ‘git’ group. After that, you need to run a one-time ‘chmod -R’ on the already created files and directories.

Installing Gitweb

Gitweb allows to view the repositories in a web interface. It only has the read access.
Example of Gitweb URL:

Install gitweb

apt-get install gitweb

Symlink the git repository to where gitweb CGI expects it

rmdir /var/cache/git
ln -s /var/lib/gitolite/repositories /var/cache/git

Configure Apache to access gitweb.

After installing gitwen Apache2 is already configured for gitweb.
To make sure the portal is not accessible from everybody on the Net make sure it is protected by Authentication for gitolite user as follows:

Set the Apache user to be allowed to read the repositories which has only access by gitolite user
vim /etc/apache2/envvars
export APACHE_RUN_USER=www-data
export APACHE_RUN_USER=gitolite

Configure the authentication
vim /etc/apache2/conf.d/gitweb
<Directory /usr/share/gitweb>
Options FollowSymLinks +ExecCGI
AddHandler cgi-script .cgi

<Directory /usr/share/gitweb>
AuthType Basic
AuthName "Private area"
AuthUserFile /etc/apache2/web.auth
Require user gitolite
Options FollowSymLinks +ExecCGI
AddHandler cgi-script .cgi

Set the gitolite user poassword for gitweb acccess

htpasswd -c /etc/apache2/web.auth gitolite
(type 2 times the password)

Enable the SSL module for Apache

a2enmod ssl
a2ensite default-ssl

Set the certificate to a proper one

vim /etc/apache2/sites-enabled/default-ssl
Set the certificates files path of the flowing 2 lines appropriately
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Restart Apache

service apache2 restart

Happy Gitting 🙂