Git: send parameters to 'post-receive' hook with the 'git push' command

Question

I have configured a post-receive hook script on a server for automatic deploy with Git, as described for example here.

So, when on my local PC I send a push on the production server:

git push production master

the post-receive hook is triggered, copying the content of the repository inside the live directory.

My question is if is there some way to pass some parameter to the post-receive hook when I send the push?

Something like this:

git push production master --params="clear-the-cache=1"

then within the hook I can read the 'clear-the-cache=1' parameter and perform additional operations.

Is there a way to do it?

Answer 1

Edit: Git version 2.10.0 added a new --push-option (aka -o) argument to git push, which provides a nice clean way to do this. Thanks to Steve Coffman for reminding me. Both server and client need to be at 2.10.0 or higher; the supplied options, one per -o or --push-option argument, are then passed to both the pre-receive and post-receive hooks as arguments.

---

Not cleanly. There are some methods by which you could provide a side channel, but I think they are all quite ugly.

Consider that every git push pushes one or more reference labels. If you push at least two labels every time, one of the labels can point to objects (commits, tags, etc) that carry additional information. The form of that additional information is up to you.

Git generally will not allow you to push arbitrary ref-space names like refs/sidechannel:

remote: error: refusing to create funny ref 'refs/sidechannel' remotely
 ! [remote rejected] refs/sidechannel -> refs/sidechannel (funny refname)

(though I accidentally discovered that github thinks this means to create a branch named refs/sidechannel. Odd.) Anyway, this means that in general, you would have to use a branch or tag name. For instance:

git push production master sidechannel

In your post-receive script, you could then check for updates to refs/heads/sidechannel and do whatever you like with them (including extract information, then delete the branch).

Alternatively, you could use ordinary annotated tags or specially formatted text in commit messages to provide side-channel data. Or, since refs/notes is now a recognized name space, use refs/notes/name as the name of the side channel.