User documentation: UsingGit
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.
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
Set git configurations:
cd /srv/git/eliot.git/ git config hooks.mailinglist firstname.lastname@example.org
Unprotect hooks/ directory:
chattr -i hooks/ cd hooks/
Create post-receive hook:
#!/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/
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
- 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
- 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