0

when I do a git pull on live server I'm logged in as root and so all modified or new files user and group are set to root:root.

I've tried this set up in my post-update hook file:

OWNER="example:example"
REPO_PATH="/home/example/public_html"

cd $REPO_PATH || exit
unset GIT_DIR
FILES="$(git diff-tree -r --name-only --no-commit-id)"
git merge FETCH_HEAD

for file in $FILES
    do 
    chown $OWNER $file
done

exec git update-server-info

When I run a git pull it just doesn't do anything.

MikeeeG
  • 331
  • 1
  • 5
  • 21
  • 2
    It definitely *shouldn't* do anything, because `git pull` does not invoke a post-update hook. – torek Dec 14 '18 at 10:27
  • doh! So what hook should I use to chown modified of new files after a git pull? – MikeeeG Dec 14 '18 at 10:43
  • 2
    Consider both `post-checkout` and `post-merge`; see contrib/hooks/setgitperms.perl for a working example. – torek Dec 14 '18 at 11:21
  • @torek if you fancy adding both your comments as a proper answer to this I will gladly mark it complete. – MikeeeG Dec 14 '18 at 15:32

1 Answers1

1

Running git pull does not invoke the post-update hook: git pull is git fetch followed by either git rebase or git merge, more or less, and rebase effectively ends with a git checkout while merge is, well, merge. (For so-called fast-forward merges, git merge does something much more like git checkout internally, but also updates the current branch name.) Thus, these two hooks are much more appropriate candidates for this kind of work.

Git includes a contrib/hooks/setgitperms.perl example script that's meant to be used in post-checkout and post-merge hooks.

(It's also worth mentioning that running git pull on a live server is not necessarily a good deployment strategy. Git itself is not a deployment system, and neither push-to-deploy nor pull-to-deploy are adequate by themselves for many real-world setups. They can work for limited subsets, but in general, consider building or using a real deployment system.)

torek
  • 448,244
  • 59
  • 642
  • 775