Hi there,
We're using a git post-receive hook to auto-minify our JS and sync our local and remote dev databases.
This is generally desirable, but occasionally not.
Is there anyway to pass an argument to the post-receive hook from git push so this can be disabled when required?
Thanks!
I would do this in another way and keep one branch that has the receive-deploy action and another branch which does not.
If you keep the post-receive hook, you could decide to run the script based on the ref name of each file.
This hook [...] takes no arguments, but for each ref to be updated it receives on standard input a line of the format:
<old-value> SP <new-value> SP <ref-name> LF
where:
<old-value>is the old object name stored in the ref,<new-value>is the new object name to be stored in the ref and<ref-name>is the full name of the ref.
So you could check the branch name from the ref-name, and for some branches, decide not to run your script.
There is no direct mechanism for passing out-of-band data from git push to (e.g.) a post-receive hook in another repository.
You will have to work with the data that is passed:
The commits that are pushed (commit messages or content).
You could disable the minification based on a particular string in the commit message of the pushed tip commit (or any of the pushed commits). Using the content itself (e.g. a file in the tree of the tip/any pushed commit) may be less desirable since the minification disabled/enabled state would to be persistent (just like the normal files, it would not change unless you made the change explicitly).
Whichever way you go the commit-based option has the downside of polluting your history with a bit of extraneous “trash” every time you wanted to push a non-auto-minified tree (or switch it on and back off if using a content-based switch).
If you are already saving the minified code back to the repository, then you are already adding extra cruft to the history, so maybe occasionally including a different bit of noise to disable minification would be okay.
You could potentially eliminate the pollution by restricting the detection to the tip commit and then discarding the tip commit if it is a “no minify” commit. Unfortunately, this has a high potential for causing confusion for anyone who pushes a tip that satisfies the “no minify” condition.
The destination ref name.
You could arrange to have any push to brach-nominify also update branch without introducing any history pollution. You would have to be careful not to rewind history though (e.g. check that the new pushed tip for branch-nominify could be used to fast-forward update branch).
Special data provided by your server.
Depending on your Git server, you may be able to tell which user is pushing. You could simply disable minification for one particular user.