Activación del enganche post-checkout después del command "git checkout -b"

La misma pregunta se hizo aquí antes, sin embargo, ambas respuestas no me ayudaron mucho.

No pude get mi post-checkout para diferenciar el git checkout de git checkout -b command git checkout -b ya que $1 (sha1 del HEAD anterior) y $2 (sha1 del nuevo HEAD) son los mismos para ambas llamadas.

Aquí está mi script post-checkout:

 #!/bin/bash echo "old HEAD: $1" echo "new HEAD: $2" echo "checkout type: $3" 

Ejecuté los siguientes commands:

 > ozgur@ozgurv:~/project (master)$ git checkout -b new_branch old HEAD: e86423aa9f45053cb45b8ec15d463bb9684526a2 new HEAD: e86423aa9f45053cb45b8ec15d463bb9684526a2 checkout type: 1 > ozgur@ozgurv:~/project (new_branch)$ git checkout master old HEAD: e86423aa9f45053cb45b8ec15d463bb9684526a2 new HEAD: e86423aa9f45053cb45b8ec15d463bb9684526a2 checkout type: 1 

Lo que bash lograr es ejecutar la lógica en el enganche post-checkout solo cuando se crea una nueva twig local, no cuando está desprotegida.

Realmente no puedes ver la diferencia, en un gancho después de la salida. 1 En cualquier caso, es posible que no desee tratar de notar la diferencia. Considerar:

 $ git branch newbr # make a new branch $ git checkout newbr # and now check it out 

Probablemente tenga sentido hacer lo que sea que haya hecho para el git checkout -b newbr aquí, y si es así, verificar el indicador -b (si puede hacer que funcione) es probablemente contraproducente. (Considere también la git checkout feature cuando existe el origin/feature y la feature sucursal local no, que crea la feature como una nueva sucursal que rastrea el origin/feature , aunque nuevamente no hay indicador -b ).

Veamos esto de nuevo, y sugeriré un enfoque diferente:

solo cuando se crea una nueva sucursal local

¿Qué pasa si, en su gancho, mantuvo una list de "todas las twigs locales vistas hasta ahora" guardadas en un file? (Tal vez .git/ozgur/branchlist sería un lugar razonable para save esto. Queremos algo que siga al repository, que es poco probable que use el git). Entonces, si el pago es un pago de tipo twig ( $3 es 1 ), compare la twig actual con la list:

 git_dir=$(git rev-parse --git-dir) || exit 1 branchlist=$git_dir/ozgur/branchlist if [ "$3" = 1 ]; then # Checked out a branch - what branch are we on now? # (Skip rest of code if we're on a detached HEAD.) curbranch=$(git symbolic-ref --short HEAD) || return # Is $curbranch in our branch list? Create empty # branch list first if needed. Can just "touch" but # this avoids changing the mod-time unnecessarily. [ -f $branchlist ] || : > $branchlist if ! grep "^$curbranch$" $branchlist > /dev/null; then echo "switching to as-yet-unvisited-branch $curbranch" echo $curbranch >> $branchlist # now we've visited it fi fi 

Esto todavía tiene un pequeño error: si elimina una twig, puede permanecer en el file de la list de twigles. Podríamos solucionarlo filtrando las twigs eliminadas con bastante regularidad (compare el contenido de $branchlist con el git for-each-ref refs/heads apropiado git for-each-ref refs/heads output), tal vez en ganchos git adicionales también. Pero podría ser suficiente para sus propósitos tal como están.


1 En realidad, hay una manera de saber, al less en sistemas que le permitirán ver un tree de processs, y observar sus arguments de command. Desde el gancho, busque el process de git checkout su count padre y vea si tiene una bandera -b . Pero luego no funciona en la git branch ...; git checkout dos pasos git branch ...; git checkout secuencia de git branch ...; git checkout , ni en twigs creadas automáticamente desde una twig ascendente.