The Issue: when multiple users have access to the same working directory, permissions issues can occur in the meta-data if any
operations are performed.
DISCLAIMER: Before you chastise me - I realize sharing a working dir is counter to what Git stands for, and I am not talking about doing anything other than read-only operations in this shared directory - we do all our work in our own local repositories.
I'm open to suggestions as to another way to do what we are trying to do, as our approach is certainly not best practice, but I'm not sure that conversation that would be useful for others to listen to. So for now let me provide some details on why we are doing this:
We have several build-masters on our team. We deploy to Linux servers, and we do our builds there, with build scripts that pull directly from Git. We are not able to use CI (such as Jenkins/cruisecontrol) at this time, so we have a repository that we checkout and do our QA builds from.
There are some git operations that we perform as part of the script. This includes some tagging of commits (stuff gets tagged as QA-current, QA-previous, etc...). So I guess we aren't actually read-only entirely. Due to the nature of the build script, we run it
'ed as a common user (let's call that user DevAdmin). I realize this might be a bad practice, and is perhaps the source of the pain, since it forces us to use a shared repo checkout.
This would all be fine, if we were always sudo'ed when in that working dir. The issue is that on occasion, one of us will do a
or something similar by accident, without being sudo'ed as DevAdmin. So most of the files in
are owned by DevAdmin (who performed the initial clone), but whenever we do this, we end up with dir's in
that contain files owned by a specific user. And these are created as group-unwritable. I've also noticed
with wrong ownership, for example. So when we try to do something as DevAdmin, we get issues.
Is there anything that we can do to fix this issue? Right now, we have to recognize that it has happened, and then get a server admin to
back to DevAdmin. Or have the user delete the meta-files in question, or at least
them to group-writable. This all seems very bad.
I've considered a couple of options that don't involve changing our build and maintenance processes dramatically:
If we removed group-write access on
and restricted it to DevAdmin, would that prevent this from happening again? This seems the most straightforward option.
Or is there a way to make everything in
t group-writable, even when it's newly created? This seems like asking from trouble.
Is there something else obvious I'm missing? I realize that the best thing would probably be to change our process so that users could work in their own repo's, but in a business setting, the repos can get very large (jars aren't separated out yet, lots of binary files, etc...), and we can't have multi-GB repos for everyone's account. Additionally, our system administrators would have a lot of work ahead of them changing their processes to allow for it.
Any thoughts are appreciated.