You would like to see how many commits per author you have in your git repository.
Just run the following command to get commits per author in your git:
git shortlog -s -n
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).
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
You would like to know what permission and for which repositories you have as a certain user when using gitolite to host your repositories.
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
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.
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
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.
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
You are trying to set up gitolite access through gitweb but the gitweb page, shows ‘no projects avaiable’ even though you have repositories available.
Try to follow the guide here.
Some of tthe most important steps for having the right access permissions are:
$ sudo usermod -a -G gitolite www-data
$ sudo vi /etc/gitweb.conf
$ sudo chmod g+r /var/lib/gitolite/projects.list
$ sudo chmod -R g+rx /var/lib/gitolite/repositories
$REPO_UMASK = 0027;
exec chpst -ugitdaemon:gitolite
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.
gem 'rails', '3.0.3'
gem 'rails', '3.0.4'
bundle update rails
git rm name_of_3.0.3_gem
git add vendor/cache
git commit vendor/cache -m 'upgrade to rails 3.0.4'
git commit Gemfile Gemfile.lock -m 'update Gemfiles to use 3.0.4'
You have modified your Gemfile in development but did not check the resulting snapshot (Gemfile.lock) into version control
You would like to host a new git repository in Gitorius.
Assuming that you have created your initial ruby on rails application, and you have git installed, you can follow the steps below:
git remote add origin firstname.lastname@example.org:my-project-name/my-git-repo.git
git add .
git commit -m "Initial commit"
git push origin master
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.
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.
After dreamhost decided to move my account that hosted the git repository to a new server, first time I’ve tried to push some changes to the git repository I was faced with the followng error:
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 699 bytes, done.
Total 7 (delta 6), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
After searching and finding out various solutions to solve the problem, none of which was specific to a server move, I’ve tried the following:
git push new_remote master
And everything should work as normal again.