Múltiples ganchos git para el mismo disparador

Tengo un post-checkout que uso localmente en todos mis repo-name/branch-name (cambia el nombre de mi session de tmux por el de repo-name/branch-name )

Para un proyecto en el que estoy trabajando, acabamos de agregar un post-checkout que le pedimos a todo el equipo que use.

No quiero agregar la lógica de mi gancho personal al gancho de todo el equipo, porque no es útil para todos, pero tampoco quiero renunciar a él.

¿Hay alguna manera de ejecutar más de un script en un único activador de git-hook? Quiero que cada git checkout ejecute el gancho post-checkout y ejecute mi gancho personal post-checkout . No puedo tener dos files con el mismo nombre. ¿Hay alguna forma de evitar eso?

Actualización: Un buen enfoque es "hacer que los dos guiones sean post-checkout la verificación". Me gusta esta idea y puede ser la solución.

Sin embargo, en este momento tenemos un paso de configuration automatizada que copy post-checkout en el directory de ganchos. Si es posible, me gustaría hacer esto de una manera que no interfiera con la configuration del equipo existente, y no requiere ajustes manuales de mi parte si vuelvo a ejecutar ese paso de installation más adelante.

Si eso no es posible, es genial, pero tengo curiosidad por soluciones aún más creativas.

Por supuesto. Cree un script de enlace post-checkout envoltura que llame a los otros scripts:

 #!/bin/sh $GIT_DIR/hooks/my-tmux-post-checkout "$@" $GIT_DIR/hooks/corporate-post-checkout "$@" 

Puede ser más elegante e iterar sobre un número arbitrario de scripts en un directory post-checkout.d o algo así, pero la idea básica es la misma.

Actualización para Steve

Para scripts que esperan input en 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 

En realidad, esto debería ser inofensivo para el primer caso, aunque si lo testing ejecutándolo manualmente, necesitarás asegurarte de networkingirigir siempre el stdin desde algún lugar (posiblemente /dev/null ).