On 5/4/2011 6:38 PM, Rowan Lewis wrote:
Hi,
I work at a web development company, a few years ago we switched from using SVN to using git. Since then a lot of little issues and improvements have been made to git, I have to thank the developers for their hard work.
However, one problem still remains. Our projects are often cloned onto a large variety of computer environments, from Linux servers to OSX and Windows desktops. Each of these environments tends to have its own requirements for file permissions, depending on how Apache and PHP have been configured.
As a result of this we're nearly constantly forced to manually set filemode to false in every repository, including submodules.
The following is the output of git status on one of our repositories with a moderate number of submodules:
# modified: extensions/asdc (modified content)
# modified: extensions/canofspam (modified content, untracked content)
# modified: extensions/db_sync (modified content)
# modified: extensions/debugdevkit (modified content)
# modified: extensions/emailtemplatefilter (modified content)
# modified: extensions/export_entry (modified content)
# modified: extensions/expressionfield (modified content)
# modified: extensions/flexdatefield (modified content)
# modified: extensions/globalresourceloader (modified content)
# modified: extensions/logsdevkit (modified content)
# modified: extensions/mpm/extension.driver.php
# modified: extensions/order_entries (modified content)
# modified: extensions/profiledevkit (modified content)
# modified: extensions/publishfiltering (modified content)
# modified: extensions/reflectionfield (modified content)
# modified: extensions/selectbox_link_field (modified content)
# modified: extensions/subsectionfield (modified content)
From this list it would appear that each of the 17 items in the extensions directory has been changed, but this is not truly the case. What actually happened was someone running chmod to give Apache access to the files.
It's a real problem, as I cannot tell which of the submodules actually has changes that I need to deal with. I'm also sure that there's probably some script-foo that I could to do automatically change filemode to false; but unfortunately my bash isn't so great, and I'm the most knowledgable in shell scripting at work.
I see three possible solutions to our woes:
1) It is/becomes possible to disable filemode when repositories are created; so only in the rare case that we need this feature would we have to change the git configuration.
2) Submodules defere the filemode preference to the parent repository; so that it only needs to be disabled once per project/repository.
3) I'm an idiot and all of my googling has failed to turn up an obvious/easy solution, and someone here points me to it.
Anyhow, thanks for listening, this email has been a long time coming.
Here are some puzzle pieces that may help you solve your puzzle. (I'm
assuming your canonical repository is on Linux.) Git does not track all
permissions, just whether a file is executable or not. So in linux a
file is stored in git, ie. the object store, as either 777 (executable)
or 666 (non-executable). Upon checkout, the permissions are modified by
the umask. Umask can only take away permissons, not add them. So if
you ensure all your files are committed with full permissions
(executable) then you can modify the checkout to do whatever you want
with the umask. Therefore, the changes you're seeing in git status are
not really saying that permissions changed in general, but specifically
saying that the permissions changed from not having any executable bits
at all to having at least one executable bit, or from having at least
one executable bit to not having any executable bits at all. See this
thread for more context and information:
http://article.gmane.org/gmane.comp.version-control.git/177583
(Although, the git-archive aspect may not apply to you, the git
permissions and umask aspects do.) With this info, I was able to do
what I needed to do with permissions while keeping filemode=true.
I am not an expert on git permissions, umask, and apache, but in my
scenario (of linux only) I was able to get these to work together and
avoid unnecessary scripting by getting a better understanding of them.
My (non-expert) understanding is that apache only needs to read files in
order to execute them. It looks like apache may need to write some of
your stuff, also. (In my scenario it does need to write to the files.)
Either way, you shouldn't care about executable bits on files for apache
access, correct? Of course dirs need to be executable so they can be
traversed, but I'm guessing they should probably be set correctly in
your object store and post-checkout worktree already by default without
you having to script to change it. IOW, maybe your permissions fixing
scripts are doing overkill by modding executable bits that don't really
need to be modified in order to accomplish your apache access. Just my
thoughts based on limited (but successful) scenarios, knowledge, and
experience. (Maybe I'm missing something here.)
v/r,
neal
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html