Reputation: 2030
I have restored a git repo from backup and it does not have the correct file permissions. Is it enough to set owner +rw on all files and directories in .git, or is it more subtle?
Is there a utility to check or reset .git file permissions?
Upvotes: 21
Views: 7246
Reputation: 1555
In addition to @Jonathan Leffler's answer, it's worth to mention the ownership of the .git
and its parent directories, too. For example:
sudo chown -v "$( id -u; ):$( id -g; )" .;
sudo chown -v "$( id -u; ):$( id -g; )" -R .git;
find '.git' -type d -exec chmod -v 775 {} \;;
find '.git/objects' -type f -exec chmod -v 444 {} \;;
find '.git/hooks' -mindepth 1 -maxdepth 1 -type f -exec chmod -v 775 {} \;;
find '.git' -type f ! -path '.git/objects/*' ! -path '.git/hooks/*' -exec chmod -v 664 {} \;;
Related:
ensure_valid_ownership()
https://stackoverflow.com/a/74209644/5113030 (git submodule update failed with 'fatal: detected dubious ownership in repository at'...)
Upvotes: 1
Reputation: 753455
Directories should have 755 permission; files should have 644 permission.
That's a pretty good rule of thumb unless you expect members of your group to make changes to your repository.
Having said that, in one of my repositories, the files under .git/objects/*
have 444 (readonly) permission for everyone. Other files are 644 as suggested.
This script, run in the top-level directory just above the .git
repository would fix the permissions:
find .git -type d | xargs chmod 755
find .git/objects -type f | xargs chmod 444
find .git -type f | grep -v /objects/ | xargs chmod 644
I started with -print0
for the first two find
commands and xargs -0
to allow for the remote possibility of spaces in file names. But the grep -v
in the third command would be difficult to manage with the -print0
format - so I omitted the space-safe notation from all the commands, knowing that git
does not create files with spacing in names under the .git
directory.
Upvotes: 36