User documentation: UsingGit
Current setup
git-core is backported on a regular basis using the procedure in infra/git.txt. Keep it up-to-date.
Repositories are in /subsystems/cvs/srv/git/project_name.git for now. git+ssh is supported in Savane's sv_membersh (delegates to git-shell). The git:// lightweight protocol is also available, check etc/xinetd.d/git.
Creating an additional repository
first, make a directory to place additional repositories:
mkdir /srv/git/lwip chgrp -R lwip /srv/git/lwip chmod g+s /srv/git/lwip
create new repository:
GIT_DIR=/srv/git/lwip/lwip-contrib.git git init --shared=all chgrp -R lwip /srv/git/lwip/lwip-contrib.git
write following to: /srv/git/lwip/lwip-contrib.git/hooks/post-update:
#!/bin/sh exec git update-server-info
make it executable:
chmod a+x /srv/git/lwip/lwip-contrib.git/hooks/post-update
forbid access to hooks:
chown -R root: /srv/git/lwip/lwip-contrib.git/hooks chattr +i /srv/git/lwip/lwip-contrib.git/hooks
add 'git-cvsserver' support:
GIT_DIR=/srv/git/lwip/lwip-contrib.git git config gitcvs.pserver.enabled 1 GIT_DIR=/srv/git/lwip/lwip-contrib.git git config gitcvs.ext.enabled 0 GIT_DIR=/srv/git/lwip/lwip-contrib.git git config gitcvs.dbname "%G/gitcvs-db/sqlite" mkdir /srv/git/lwip/lwip-contrib.git/gitcvs-db -m 755 chown nobody /srv/git/lwip/lwip-contrib.git/gitcvs-db
Enabling Commit Notifications
Set git configurations:
cd /srv/git/eliot.git/ git config hooks.mailinglist eliot-dev@nongnu.org
Unprotect hooks/ directory:
chattr -i hooks/ cd hooks/
Create post-receive hook:
post-receive file:
#!/bin/bash exec run-parts hooks/post-receive.d
Make script executable:
chmod a+x post-receive
Create post-receive.d directory:
mkdir post-receive.d# cd post-receive.d
Link to post-receive-email script in post-receive.d directory:
ln -s /usr/src/git/contrib/hooks/post-receive-email post-receive-email
Protect hooks/ direcotry again:
cd ../.. chattr +i hooks/
Renaming a branch
This needs some rationale and justification because during normal operation we never want to rewind a branch. It causes problems for anyone who has pulled from the branch. Normally branches only move forward. But sometimes renaming a branch is the best solution to a problem.
Sometimes a user has munged a commit, has pushed the desired branch onto a temporary branch (call it new-master), and wishes to have the new temporary branch become the master branch as the correction.
Verify the current and future state of the repository:
GIT_DIR=/srv/git/exampleproject.git git branch GIT_DIR=/srv/git/exampleproject.git git log GIT_DIR=/srv/git/exampleproject.git git log new-master
Save the current branch for a for backup:
GIT_DIR=/srv/git/exampleproject.git git branch -m master master-broken
Move the new branch into place as master:
GIT_DIR=/srv/git/exampleproject.git git branch -m new-master master
At this time the "current" branch will be shown to be master-broken:
GIT_DIR=/srv/git/exampleproject.git git branch master * master-broken
(There is likely a less heavy-handed command to do this. This is the only way I know how at this moment. I would welcome an improvement here. Normally with a working directory 'git checkout' would be used to set this.) The current branch reflog was moved when the branch was moved and is now set to master-broken and needs to be updated to point to master. Since this is a raw repository update the HEAD file directly:
echo ref: refs/heads/master > /srv/git/exampleproject.git/HEAD
Verify the current status us as desired:
GIT_DIR=/srv/git/exampleproject.git git branch * master master-broken
Verify that the change is correct. Better to leave the broken branch around for a while than to remove it too soon and lose something that should not have been lost. Then clean up and discard the broken branch:
GIT_DIR=/srv/git/exampleproject.git git branch -D master-broken
Task List
- Sub-repositories
- We need to decide how to allow multiple repositories, or stick with a single one. repo.or.cz seems to use project_name.git and project_name/forks.git, which sounds cool.
- repo.or.cz also implements the concept of "forks": http://repo.or.cz/m/regproj.cgi?name=git/ which can be used to save bandwidth.
- Implement repository instanciation in Savane - more generally git support. [Basic Git support implemented]?
- Repository optimization (packing, pruning) needs to be done at some points, probably via hooks. git:// doesn't allow this kind of operations. At kernel.org, people usually have shell access and a private/non-shared repository, so they don't have this kind of issues. The doc says: "packing every 4-5MB of loose objects accumulation may be a good rule of thumb." (http://www.kernel.org/pub/software/scm/git/docs/everyday.html#Basic%20Repository). Apparently it's done by git when there's a lot of objects committed at once, but it may be necessary to do it manually (git gc --auto) from time to time.
- Hooks management, as usual.
- xyz.git/hooks/update for a simple mail-on-commit
- CIA: http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#ciabot
Links
- http://lists.gnu.org/archive/html/savannah-hackers/2006-05/msg00069.html , http://lists.gnu.org/archive/html/savannah-hackers/2006-06/msg00010.html : thread about implementing git at Savannah
- http://git.or.cz/gitwiki/InterfacesFrontendsAndToolsWishlist#Savane http://git.or.cz/gitwiki/GitProjects : mention Savane there :)
- http://git.or.cz/gitwiki/GitHosting http://git.or.cz/gitwiki/GitProjects : mention Savane there :)
can we use gitorious code for managing git instance of savannah? --j4v4m4n, Tue, 10 Aug 2010 12:14:28 +0000 reply
- gitorious has pretty good git management interface which allow people to host cloned repos easily, but it lacks full project management features like mailing list and trackers. If we can join the two, it would be unbeatable!