Git always pulls files that I cant edit

Question

When I pull files down on OSX with terminal, I don't have edit permissions by default.
How can I change that?

---

kirkstrobeck:atheycreek kirkstrobeck$ ls -lad ~ . .git
drwxrwxrwx   8 kirkstrobeck  staff   272 May 24 18:20 .
drwxrwxrwx  16 kirkstrobeck  staff   544 May 25 10:58 .git
drwxr-xr-x+ 92 kirkstrobeck  staff  3128 May 24 15:17 /Users/kirkstrobeck

---

kirkstrobeck:~ kirkstrobeck$ umask
0022

---

kirkstrobeck:atheycreek kirkstrobeck$ ls -l
total 8
-rwxrwxrwx  1 kirkstrobeck  staff  2143 Mar  6 14:49 README.md
drwxrwxrwx  4 kirkstrobeck  staff   136 May 23 14:45 www
kirkstrobeck:atheycreek kirkstrobeck$ 

---

Note: I ran these terminal commands after fixing the issue with CHMOD, but I do that every time, because it pulls down the wrong perms.

Answer 1

Try checking core.sharedRepository this can be set so umask is not the default for permissions:

From git-config(1):

When group (or true), the repository is made shareable between several users in a group (making sure all the files and objects are group-writable). When all (or world or everybody), the repository will be readable by all users, additionally to being group-shareable. When umask (or false), git will use permissions reported by umask(2). When 0xxx, where 0xxx is an octal number, files in the repository will have this mode value. 0xxx will override user’s umask value (whereas the other options will only override requested parts of the user’s umask value). Examples: 0660 will make the repo read/write-able for the owner and group, but inaccessible to others (equivalent to group unless umask is e.g. 0022). 0640 is a repository that is group-readable but not group-writable. See git-init(1). False by default.

So

git config core.sharedRepository all

Would turn give everyone access.

Answer 2

When you say you don't have edit permissions - what exactly do you mean?

Note: I ran these terminal commands after fixing the issue with CHMOD

That means the output isn't helpful. All these permissions show:

kirkstrobeck:atheycreek kirkstrobeck$ ls -lad ~ . .git
drwxrwxrwx   8 kirkstrobeck  staff   272 May 24 18:20 .
drwxrwxrwx  16 kirkstrobeck  staff   544 May 25 10:58 .git
drwxr-xr-x+ 92 kirkstrobeck  staff  3128 May 24 15:17 /Users/kirkstrobeck

is that you do have edit permissions for everything listed - to be expected if you've previously ran chmod -R 777 . on the folder.

The more relevant permissions are those of the file and folder for the things you're trying to edit. With a specific example of a command, the errors it generated and the permissions of relevant files - would come a specific answer, in the absence of that, some educated guess work:

Write perms aren't a git problem

Git doesn't store folders at all, and only stores the executable permission for files. you can demonstrate this to yourself with something like this:

[andy@work:/tmp/so/original]$ git init
[andy@work:/tmp/so/original]$ touch 0700
[andy@work:/tmp/so/original]$ touch 0600
[andy@work:/tmp/so/original]$ touch 0500
[andy@work:/tmp/so/original]$ touch 0400
[andy@work:/tmp/so/original]$ chmod 0700 0700
[andy@work:/tmp/so/original]$ chmod 0600 0600
[andy@work:/tmp/so/original]$ chmod 0500 0500
[andy@work:/tmp/so/original]$ chmod 0400 0400
[andy@work:/tmp/so/original]$ git add *
[andy@work:/tmp/so/original]$ git commit -va
[master (root-commit) a304e1b] adding files with the named permissions
0 files changed
create mode 100644 0400
create mode 100755 0500
create mode 100644 0600
create mode 100755 0700
[andy@work:/tmp/so/original(master)]$ ls -la 
total 12
drwxr-xr-x 3 andy users 4096 May 28 14:51 .
drwxr-xr-x 3 andy users 4096 May 28 14:48 ..
-r-------- 1 andy users    0 May 28 14:48 0400
-r-x------ 1 andy users    0 May 28 14:48 0500
-rw------- 1 andy users    0 May 28 14:48 0600
-rwx------ 1 andy users    0 May 28 14:48 0700
drwxr-xr-x 8 andy users 4096 May 28 14:51 .git

The above shows (with ls -la) file permissions indicated as both numbers (the filenames) and read, write, executable perms (on the left). Only the two files 0500 and 0700 have executable permissions.

[andy@work:/tmp/so/checkout]$ git init
Initialized empty Git repository in /tmp/so/checkout/.git/
[andy@work:/tmp/so/checkout]$ git pull ../original/
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../original
* branch            HEAD       -> FETCH_HEAD
[andy@work:/tmp/so/checkout(master)]$ ls -la 
total 12
drwxr-xr-x 3 andy users 4096 May 28 14:52 .
drwxr-xr-x 4 andy users 4096 May 28 14:52 ..
-rw-r--r-- 1 andy users    0 May 28 14:52 0400
-rwxr-xr-x 1 andy users    0 May 28 14:52 0500
-rw-r--r-- 1 andy users    0 May 28 14:52 0600
-rwxr-xr-x 1 andy users    0 May 28 14:52 0700
drwxr-xr-x 8 andy users 4096 May 28 14:52 .git
[andy@work:/tmp/so/checkout(master)]$

The above indicates that the checkout has default file permissions (those dictated by umask) with the addition of being executable if committed as executable.

Knowing the above should help you focus on where the real problem lies.

Fixing file permissions

If your checkout has wrong permissions, you can fix them with a command like this:

# make sure all files are owned by you
sudo chmod -R andy:users .
# reset to default permissions
sudo find . -type d -exec chmod 0755 {} \; -or -type f -exec chmod 0644 {} \;

Double check that for files mentioned in whatever error message you have; the permissions of the file are now 0644, and the folder it's in are 0755.

With file permissions corrected, you should be good to go.

Note that you need executable permissions on folders to be able to find and manipulate the contents. If you don't have executable perms on a folder you'll get permission errors doing almost anything within it. But, again, git doesn't store folders at all, it's not git-related if that's the problem.

If that made any changes to your repo you can commit them with:

git commit -am "Resetting file permissions to their default values"

That'll only be committing changes to the executable property of files, and is just a cleanup step - not fixing anything which would cause permission issues to someone else checking out the repo.

Ignoring file permissions

If you want your checkout to entirely ignore permissions you apply to your checkout, you can use:

git config core.fileMode false

in this way git won't consider file-permission changes you apply to your checkout as changes to commit - but that's not likely to be relevant given the information available.

Answer 3

git works according to your umask settings. The only working-directory permissions that git manipulates are the execute bits. If you can't write, you must have your umask set very restrictive, e.g., 0277 would remove w for yourself and rwx for group and other.

Try running umask to see what you're currently set to, and umask 022 to set a typical setting (022 = take away w for group and other).