Reputation: 7295
Tutorial after tutorial on setting up a git repo on your server are essentially all the same -- and they go like this:
git/project.git
off your root directory of your servergit/project.git
using git init --bare
git/project.git/hooks
then touch post-receive
#!/bin/bash\n 2 GIT_WORK_TREE=/path/to/your/vc'd/project git checkout -f
chmod +x post-receive
git clone ssh://[email protected]/git/project.git
This is all fine, and I can indeed push to the git/project.git
and end up with those files in the path/to/your/vc'd/project
but I'm looking to understand...
Why use the hook at all?
It leaves you without the ability to pull your path/to/your/vc'd/project/
on your local machine.
Why not just git init
the path/to/your/vc'd/project
and clone
it on your local machine?
Further, if anyone could explain how to get git pull
functionality on the local side for the path/to/your/vc'd/project
with this hooking method, it would be much appreciated
Thanks :)
Upvotes: 1
Views: 67
Reputation: 1327754
It is best practice to push to a bare repo rather than a repo with a working tree.
That way, the user cannot be surprise to see the file pushed not be displayed, because the target repo would have one branch checked out and the user is pushing another branch.
Making the target repo update automatically a working tree based on what the user is pushing could be too dangerous: if you push the wrong branch, you replace your working tree content immediately.
This is different from pushing to a bare repo and updating an external working tree through a hook: you can do some control in said hook.
For more, see "all about "bare" repos -- what, why, and how to fix a non-bare push".
Upvotes: 2