Problem
You would like to see how many commits per author you have in your git repository.
Solution
Just run the following command to get commits per author in your git:
git shortlog -s -n
Git stats commits per author
Reply
Category Archives: git
Exporting all the commits from git after a certain date
Problem
You would like to export all the commit comments from your git repository into a text file, after a certain date (ie the last live deployment date).
Solution
Use the git log option with the after parameter and redirect the output to a text file like:
git log --after="2012-05-14" --pretty=oneline >> /path/to/file/for/the/commits/export.txt
Some more useful options can be found here
Find out the repositories permissions in gitolite
Problem
You would like to know what permission and for which repositories you have as a certain user when using gitolite to host your repositories.
Solution
Assuming that your gitolite user is gitolite and you have two different servers (server_a and server_b) with two different users (deploy_a and deploy_b) you can find out the permsissions by running the following:
$server_a/deploy_a: ssh gitolite@git_host info $server_b/deploy_b: ssh gitolite@git_host info
Using gitolite in a non standard ssh port
Problem
You have moved your gitolite server or you want to be able to access your gitolite server behind a firewall and port 22 for ssh is no longer available.
Solution
Edit your .git/config file and replace the line with :
url = git_user_name@http://server_ip:repo_name.git
to the following:
url = ssh://git_user_name@external_ip:non_standard_ssh_port/repo_name.git
problem using capistrano on deployment server after server ip address change
Problem
After changing the IP address of your staging server the cap deploy does not work any more and gives you the following error:
** [192.168.0.50 :: err] Host key verification failed.
** [192.168.0.50 :: err] fatal: The remote end hung up unexpectedly
Solution
You would need to login to your staging server (as your deployment user) and do an initial checkout for one time for the ssh keys to work.
So you could do something like the following:
$ ssh user_name@staging_server
$sh -c 'git clone -q git_user@192.168.0.50:repo_name /some/tmp/dir/temp_repo_name
Make sure that you reply ‘y’ to the question about the authenticity of the host as in:
The authenticity of host '192.168.0.50 (192.168.0.50)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xxb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.50' (RSA) to the list of known hosts.
Next delete the newly created git project from your tmp directory, and then you should be able to use cap deploy as normal again from your development pc
.gitignore seems that is not working
Problem
Your .gitignore file seems that is not working. You have added files there like db/schema.rb, but it keeps tracking the changes to it.
Solution
The cause is that the file was added to git version control before it was added in the .gitignore file. To remove the file from git tracking but without removing it from the filesystem use the following:
$ git rm --cached filename_not_to_be_tracked
Gitweb access to gitolite repository
Problem
You are trying to set up gitolite access through gitweb but the gitweb page, shows ‘no projects avaiable’ even though you have repositories available.
Solution
Try to follow the guide here.
Some of tthe most important steps for having the right access permissions are:
- Add the www-data user in the gitolite group by:
$ sudo usermod -a -G gitolite www-data - Add the paths to the repositories and the projects list:
$ sudo vi /etc/gitweb.conf
$projectroot ="/var/lib/gitolite/repositories";
$projects_list="/var/lib/gitolite/projects.list"; - Change the permissions in the repositories:
$ sudo chmod g+r /var/lib/gitolite/projects.list
$ sudo chmod -R g+rx /var/lib/gitolite/repositories - Change permissions in the /var/lib/gitolite/.gitolite.rc file to allow access to the repositories:
$REPO_UMASK = 0027; - Finally change the git-daemon to run with the gitolite group permissions in the file /etc/sv/git-daemon/run:
exec chpst -ugitdaemon:gitolite
Upgrading your Rails 3.0.3 application
Problem
After the announcements in the previous posts about the security vulnerabilities in Rails 3.0.3, you would like to update your application and deploy with the latest 3.0.4 version.
Solution
- Change your Gemfile to replace
gem 'rails', '3.0.3'
with
gem 'rails', '3.0.4' - Run:
bundle update rails - Remove the old gems by using:
git status
and then
git rm name_of_3.0.3_gem - Add the new gems to your git
git add vendor/cache - Check in to your repository the new files
git commit vendor/cache -m 'upgrade to rails 3.0.4' - Make sure that you also check in both your Gemfile and Gemfile.lock into your git repository
git commit Gemfile Gemfile.lock -m 'update Gemfiles to use 3.0.4'
otherwise when you try to deploy you will see the error:
You have modified your Gemfile in development but did not check the resulting snapshot (Gemfile.lock) into version control - push everything to your git repository:
git push - Deploy your application with capistrano as usual:
cap deploy - Your new gems for 3.0.4 should be installed on the share/bundle folder
Creating a new git repository in Gitorious
Problem
You would like to host a new git repository in Gitorius.
Solution
Assuming that you have created your initial ruby on rails application, and you have git installed, you can follow the steps below:
- Create a new account in Gitorious
- Copy your public ssh key (usually in ~./ssh) to your new account in Gitorius
- Create a new project in Gitorius (ie My Project)
- Add a new repository in Gitorius (ie My Git Repository)
- On your local development host initialise the git repository in your project’s directory:
git init - Add your remote hosting repository:
git remote add origin git@gitorious.org:my-project-name/my-git-repo.git - Add your project files:
git add . - Do your initial commit:
git commit -m "Initial commit" - Push your project to the Gitorious repository:
git push origin master
capistrano deployment fails after dreamhost server move
Problem
You have set up your capistrano recipe for deployment to dreamhost using password less logins, but after dreamhost moves your git repository server to a different server, the deployment breaks, with ‘permission denied’ when trying to get the git repository.
Solution
As the server was moved you would need to copy your ssh public key from the deployment server to the new server again for the password-less logins to work again.
Follow the details here how to copy your public key across, login in once with your password, and after that your capistrano recipe should be working again as normal.