We're increasingly reliant on hooks but our top-level command-line facility to interact with them pre-dates the phase hook support. We just have a --skip_hooks option which skips the run of all hooks. Things that we'd also like, in no particular order:
Say we're running 2x pre-sync hooks and the sync hook fails, currently you have to re-run the path of the sync hook, but you have no idea if there were any post-sync hooks or anything else that needs to run.
Whenever we have a sequence of hooks we're running we should write that sequence to .git/deploy/sequencer, then you could do git-deploy --continue, git-deploy --abort etc. See ./Documentation/sequencer.txt in git.git for generic support for this (which we may or may not be able to use).
Continuing would try to re-run the failing hook (e.g. a broken sync hook), you could run that in a loop until it worked, and it would make sure to run the remaining hooks (if any), and finish appropriately.
Now that we have phase hooks maybe this should be something like this:
# like --skip_hooks now, we could alias that to this:
# skip all log hooks
# skip several types of hooks
# skip a specific hook
# or just reply on it matching against the right thing out of all the hooks
While we're at it we could also include --add-hook, if we did that we could completely emulate the current hook support with command-line switches:
git-deploy --add-hook=start./some/path/000.start.pl start
Or something like that.
One of the things that comes to my mind when skiping or adding hooks is also a mechanism like the one used in git's interactive rebase.
So populate a file with all the hooks that are supposed to be run, load it into $EDITOR, and allow the user to comment out (or other things we think of) specific lines (hooks). Saving and quitting the $EDITOR would continue the process and use only the hooks chosen.
git-deploy --interactive-hooks start
I really like the sequencing approach, so if we were to employ something similar to what I proposed above, we would have to persist the chosen hooks so git-deploy --continue would't run hooks the user commented out before the process was interrupted.
This would be quite useful, in the end I resorted to having something like this as my hook file.
This makes it a little more interactive and I can decide at runtime if I want to skip the hook or not.
echo "# Do you want to do a fresh build of Dojo and Static Assets?"
read -n1 -p "(y/n)?"
[[ $REPLY = [yY] ]] && perl /var/www/site.com/bin/scripts/hooks/apps/common/git-build-static.pl