8

I have a post-checkout hook that I use locally in all of my repos (it renames my tmux session to repo-name/branch-name)

For a project I am working on, we just added a post-checkout hook that we're asking the whole team to use.

I don't want to add my personal hook's logic to the team-wide hook, because it's not useful to everyone, but I also don't want to give it up.

Is there a way to have more than one script execute on a single git-hook trigger? I want every git checkout to execute the teamwide post-checkout hook and execute my personal post-checkout hook. I can't have two files named the same thing -- is there a way to get around that?

Update: A good approach is, "make post-checkout call the two other scripts. I like this idea, and it may be the solution.

However, right now we have an automated setup step that copies post-checkout into the hooks directory. If possible, I'd like to do this in a way that doesn't interfere with the existing team setup, and doesn't require manual tweaking on my part if I run that install step again later.

If that's not possible, that's cool, but I'm curious about even more creative solutions.

3
  • What's wrong with renaming the two scripts and have a third one called post-checkout that calls them both?
    – jub0bs
    Commented May 7, 2015 at 14:44
  • If the automated setup copies some file called post-checkout into the hooks folder, that's the file that Git is going to use for that hook; there is little you can do about that. I'm afraid some manual tweaking on your part is required, here. After all, post-checkout is a client-side hook. If your team wants to enforce some policy, they should leave client-side hooks alone (they're your business, not your team's) and use server-side ones instead.
    – jub0bs
    Commented May 7, 2015 at 14:57
  • That gist does what you need: gist.github.com/mjackson/7e602a7aa357cfe37dadcc016710931b
    – thoroc
    Commented Jun 11, 2020 at 7:27

1 Answer 1

8

Sure. Create a wrapper post-checkout hook script that calls the other scripts:

#!/bin/sh

$GIT_DIR/hooks/my-tmux-post-checkout "$@"
$GIT_DIR/hooks/corporate-post-checkout "$@"

You could get fancier and iterate over an arbitrary number of scripts in a post-checkout.d directory or something, but the basic idea is the same.

Update for Steve

For scripts that expect input on stdin:

#!/bin/sh

tmpfile=$(mktemp hookXXXXXX)
trap "rm -f $tmpfile" EXIT
cat > $tmpfile

$GIT_DIR/hooks/my-tmux-post-checkout "$@" < $tmpfile
$GIT_DIR/hooks/corporate-post-checkout "$@" < $tmpfile

This should actually be harmless to use for the first case as well, although if you test it by running it manually you would need to make sure you always redirect stdin from somewhere (possibly /dev/null).

6
  • This is a good solution, and may be the path I take. I expanded my question a bit in response; I'd love to know if there's a way to do it without interfering with the existing setup.
    – asfallows
    Commented May 7, 2015 at 14:52
  • I don't see this as an effective way because some tools like "git review" would override the default hook trigger. The only safe way to implement this is to make git support multiple triggers itself.
    – sorin
    Commented Apr 13, 2017 at 11:12
  • git review only overrides the default hook trigger if you ask it to. You could manually configure the git review hook without a problem. In general, I don't think anything should be overwriting your git hooks without your permission; if something does, that thing is broken.
    – larsks
    Commented Apr 13, 2017 at 11:17
  • 1
    Note that while this works nicely for hooks which receive parameters, such as post-checkout, it will not work for hooks which receive data on stdin, such as post-receive.
    – Steve
    Commented Nov 7, 2017 at 21:13
  • @Steve, fixed that for you.
    – larsks
    Commented Nov 7, 2017 at 21:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.