Johannes Schindelin wrote: > Hi, > > On Thu, 22 Dec 2005, Andreas Ericsson wrote: > > >>Johannes Schindelin wrote: >> >>>Okay, so there you are. You have a write-shared repository with the HEAD >>>checked out. Somebody wants to push to that with different credentials than >>>the user who checked out the files. Do you plainly deny updating the current >>>HEAD? >>> >>>If you do, then you better give the pushing user (pun intended) a way to >>>update the checked out files. You can do this by (tadaah) setting the umask >>>to 0002 also for working files. >>> >> >>Ahh. Sorry. We use this method a lot, really, but always only for running gitk >>and archaeology tools to check newly pushed changes, so the write-shared repo >>is only write-shared for remote users, and the local one never does a commit. >>It's perhaps a bit of a weird setup, but it lets you get an overview faster >>than gitweb and works well enough with samba. Noted should be that having the >>repo checked out is merely a convenience thing to let one browse the files at >>leisure. People know to do >> git checkout -f HEAD >> >>whenever they want to dig around. > > > Better to do this with a post-update hook, right? You can't forget to > checkout this way. *Plus* you can make sure the umask is correct in the > hook. > What prevents you from setting umask 002 in the hook? If the files are already checked out with some other (write-denying) umask by some other user it will fail regardless of where the umask comes from. > >>>Yes, we could find out exactly where writes happen inside GIT_DIR and plug >>>in shared.umask which is only applied in these cases, but I am totally >>>unconvinced that this is worth the hassle. In my cases, I am perfectly >>>helped by a umask which is respected throughout git, and the patch is simple >>>enough to be reviewed in 5 minutes. >>> >> >>But adding >> >> umask 002 >> >>to /etc/bashrc would do exactly the same thing, so why have it a setting for >>the repository only? In my experience, most servers used for hosting git repos >>host *lots* of them (look at master.kernel.org), so a server-wide setting >>really makes much more sense. If the server admin can't be bothered you can >>always change $HOME/.bashrc. > > > In my very special setup, it is a server on which you have your personal > files, too. So, setting umask = 0002 globally is not an option. > scp -p preserves the umask you have on your desktop/laptop, so unless you frequently do ssh somewhere "echo 'Gawds, this is an awkward way of editing files' >> somefile" you should be good with the bashrc setting. You can override it from bash_profile to make sure you get a safely sane umask when logging in interactively. > >>So long as people remember that .bash_profile isn't read for non-interactive >>shells this should do nicely. If they can't remember that they won't remember >>adding the setting to the repository either. > > > Problem is, what if one of your users is a tcsh zealot? Or simply forgot > to set it. Trouble in China. Also, I simply can not memorize what startup > script gets called when. > tcsh zealot? Not familiar with that one. If you're trying to cover every angle I think you'll be in for a disappointment though. Users are usually fairly ingenious when it comes to finding ways of causing trouble. As for forgetting to set it, I was talking about the /etc/bashrc file here. There is a /etc/cshrc as well, although this tcsh zealot shell might ignore it. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Dec 23 02:53:48 2005
This archive was generated by hypermail 2.1.8 : 2005-12-23 02:53:54 EST