5

Me and my colleagues have a shared Website repo. We are all on Windows 7 64 bit pushing to Ubuntu 10.04. Below is our setup in case this is in question.

local->hub->website

We push to the hub, which is a bare repo, then with a post-update hook in the hub cds to the website repo and pulls the changes from the hub to the website. This is done because the website is live and always checked out and can't be pushed to.

When I'm on my local and I commit a new folder/file it states the below with the create mode of 100644

$ git commit -a -m "testing permissions"
[master 865b809] testing permissions
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 test.php

When I push these changes to the repo it creates the folders as 755 and files as 644 when I need them to be 775 and 664. As long as I'm only editing files the permissions at least stay the same. The only problem is on creation.

On the shared repo we have core.sharedrepository = 0660 which I thought meant it would set permissions as I needed. Also our umask in our .bashrc is set to 002.

Here is my local config

[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
hideDotFiles = dotGitOnly

It seems as though our local is determining the permissions and ignoring what is setup on our shared repo. How can I get the create mode to be 100664.

EDIT

Hub config

[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedrepository = 0660
[receive]
denyNonFastforwards = true

Website config

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
sharedrepository = 1
[receive]
denyNonFastforwards = true

EDIT2

As Kalle Pokki below pointed out in her comments. This issue is that when using GIT and pushing it is running non-interactively so my umask setup doesn't work. I've updated my post-update for my repo to set the umask to 0002 everytime anyone pushes.

Henesnarfel
  • 2,129
  • 1
  • 16
  • 18
  • Do you have the core.sharedRepository option in the website git config? – stark Jan 14 '13 at 19:57
  • I don't think `sharedRepository` will control the permissions when you pull from the hub to the website. That's only to prevent permission issues on the hub when you have several users sharing the repository. Are you sure the account on your website has its umask set correctly to 002 when pulling? Depending on how you're doing that, perhaps the shell startup file that sets the umask isn't actually being run. See http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files – jjlin Jan 14 '13 at 20:09
  • @stark I've added the configs as they are on the hub and the website – Henesnarfel Jan 15 '13 at 13:28
  • @jjlin The umask is correct because if I ssh into the server it creates files and folders with the correct permissions of 775 and 664. The only issue is when we are pushing new folders/files that don't yet exist on the server. – Henesnarfel Jan 15 '13 at 13:31
  • Permissions are something you only need to worry about during deployment. Git is *not* a deployment tool, despite efforts to use it as one. – chepner Jan 16 '20 at 13:14

2 Answers2

3

From what I can tell, git doesn't store file permissions at the level you want. Having 644 or 664 files depends purely on umask.

core.sharedrepository only deals with the file permissions of the git database, not the permissions of the files stored in the repository.

As you already have the post-update hook to check out the repository in the web server, I'd suggest to add a chmod script there. Something like

find /path/to/website -type d | xargs chmod 775
find /path/to/website -type f | xargs chmod 664

EDIT: I'm quite confident your ssh/git server has different umask than what you have when logged in interactively. Perhaps you should set the umask explicitly at the beginning of the post-update hook. See the following where I have the additional file '1' in the tmp branch that doesn't exist in the master branch:

$ umask 0022
$ git checkout tmp
Switched to branch 'tmp'
$ ls -l 1
-rw-r--r-- 1 kp kp 5 2013-01-15 15:53 1
$ git checkout master
Switched to branch 'master'
$ umask 0002
$ git checkout tmp
Switched to branch 'tmp'
$ ls -l 1
-rw-rw-r-- 1 kp kp 5 2013-01-15 15:53 1
Kalle Pokki
  • 4,939
  • 2
  • 17
  • 18
  • I'd rather not have to add those chmod's as for some reason we may have files or directories that are locked down a bit more. What seems to be the issue is that when I run the commit statement on my local to add new folders/files my local git uses the create mode of `100644`. I need to make this be `100664` instead. – Henesnarfel Jan 15 '13 at 13:34
  • Edited my response about umask. – Kalle Pokki Jan 15 '13 at 14:00
  • @Henesnarfel git simply doesn't track permissions. In fact, it refuses to. Turns out there are enough mutually-exclusive definitions of how to do it right, all of which can be whipped up with simple scripting, that the simple scripting is the right way to implement it. Plus, those rules are best left per-repo, because there's repo purpose and host OS to consider. – jthill Jan 15 '13 at 16:41
  • @KallePokki From your edit I've set the `umask` within our post-update to `0002` this seems to fix the permissions issue. But I would think there would be somewhere that this could be set by default. If I `ssh` into the server and perform `umask` it returns `0002` why doesn't git or whatever is happening recognize this? – Henesnarfel Jan 15 '13 at 20:08
  • Git just doesn't track the permissions by itself. It doesn't track file ownership either. There's no need to be an umask setting in git, as that is handled by the operating system in a standard way. The reason umask is set for your interactive session but not for the post-update hook, is that .bashrc is only read for interactive sessions. – Kalle Pokki Jan 15 '13 at 20:16
  • @KallePokki is it possible to set the `umask` for non-interactive within my profile and not within the system as the default. I've found where I can set it for the entire system but I only want this for my account. – Henesnarfel Jan 16 '13 at 14:17
  • If you can pass the BASH_ENV environment variable to the starting git server, bash will source the file pointed by it when it starts non-intaractively. It seems a lot simpler and more explicit to set the umask in the post-update script, though. – Kalle Pokki Jan 16 '13 at 15:00
2

It's caused by your filemode=false

refer to http://www.gelato.unsw.edu.au/archives/git/0609/28190.html

Ignore executable bit when adding files if filemode=0.

If the user has configured core.filemode=0 then we shouldn't set the execute bit in the index when adding a new file as the user has indicated that the local filesystem can't be trusted.

This means that when adding files that should be marked executable in a repository with core.filemode=0 the user must perform a 'git update-index --chmod=+x' on the file before committing the addition.

Signed-off-by: Shawn O. Pearce Signed-off-by: Junio C Hamano

Nathan Wailes
  • 9,872
  • 7
  • 57
  • 95
yinyin.xiao
  • 21
  • 2