Permissions are a pest.
Basically, you need to make sure that all of those developers can write to everything in the git repo.
Skip down to The New-Wave Solution for the superior method of granting a group of developers write capability.
The Standard Solution
If you put all the developers in a specially-created group, you can, in principle, just do:
chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo
Then change the umask
for the users to 002
, so that new files get created with group-writable permissions.
The problems with this are legion; if you’re on a distro that assumes a umask
of 022
(such as having a common users
group that includes everyone by default), this can open up security problems elsewhere. And sooner or later, something is going to screw up your carefully crafted permissions scheme, putting the repo out of action until you get root
access and fix it up (i.e., re-running the above commands).
The New-Wave Solution
A superior solution—though less well understood, and which requires a bit more OS/tool support—is to use POSIX extended attributes. I’ve only come to this area fairly recently, so my knowledge here isn’t as hot as it could be. But basically, an extended ACL is the ability to set permissions on more than just the 3 default slots (user/group/other).
So once again, create your group, then run:
setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX
This sets up the extended ACL for the group so that the group members can read/write/access whatever files are already there (the first line); then, also tell all existing directories that new files should have this same ACL applied (the second line).
Hope that gets you on your way.
You should definitely be able to get this running under a non-system user. Pick/create a user to run Hudson then try connecting to the server using ssh user@host. If it asks for a password it isn't finding you key obviously.
In that case, double check that the key is loaded into pageant (you need to get pageant to load the relevant key from disk every time it starts), and that the GIT_SSH environment variable is set.
One other way you could do this is set your GIT_SSH environment variable to include a reference to the key. I currently do this with tunnelier and SV, so eg my SVN_SSH variable is "sexec -pk=1" where sexec is tunnelier's ssh CLI and -pk=1 tells it to use my private key in slot 1.
Best Answer
I assume you're asking
Is this likely to result in repository corruption?
If so, the answer is No.
If you're using the repository the way it's designed to be used (clone, work, commit, push) this should work fine, even if the push target is a UNC path (
git
will treat it as if you were pushing to a local path, and deal with locking accordingly).You may however encounter permissions-related problems -- you're going to want to be sure all the users who are supposed to have access to the repository have appropriate NTFS permissions (group memberships, etc).
You may also want to check out this Stack Overflow question about setting up git servers on Windows to see if there's a cleaner way that will work for you.