estado de git se confunde al cambiar twigs en una secuencia de commands

Tengo un process de compilation para producir RPM. El equipo usa numbers de lanzamiento de rpm para ayudar a rastrear la información de la versión. Se ven como <program_name>-<version>-<rel_num>.<os_type>.<arch>.rpm ; donde lo siguiente es verdadero:

  • la versión es el patrón de versión semántica MAYOR . MENOR . PARCHE
  • rel_num es simplemente un integer cada vez mayor almacenado en control de revisión para ayudarlo a ser único
  • os_type es el7 para Enterprise Linux 7
  • arco como se esperaba x86_64 o lo que tienes

El proyecto en el que estoy trabajando tiene su fuente almacenada en git. Este process de número de versión para los RPM se henetworkinga de la subversión (donde residen la mayoría de los proyectos que admite nuestro equipo).

Para mantener la singularidad, he creado una twig llamada rpm para el proyecto que tiene un directory único que contiene un file llamado rpm_build_num . La idea es que este file solo resida en la twig rpm. Durante el process de creación, se llama a un script de BASH para que compruebe la ramificación de rpm, haciendo una nueva twig basada en el origin/rpm si no existe: incremente el número de compilation y luego empújelo nuevamente al control remoto. Una vez que se completa esto, la secuencia de commands restaura la twig antes de salir. En resumen BASH

 stonetworkingBranch=$(git branch | awk -e '/^\* / {print $2}') git branch | grep -q rpm if [[ ${PIPESTATUS[1]} != 0 ]]; then git checkout -b rpm origin/rpm else git checkout rpm fi # fetch and merge origin/rpm if needed cd path/to/dir echo (( $(cat rpm_build_num) + 1 )) > rpm_build_num git add rpm_buid_num git commit -m "incrementing the build number" git push origin rpm cd - git checkout ${stonetworkingBranch} 

El problema es que, por razones que aún no entiendo, a veces el process de creación, iniciado desde el intérprete de commands del shell, se pierde con respecto a qué twig está usando en realidad. Estoy siendo muy cuidadoso en cada etapa de este process para comenzar varias cosas, como esta secuencia de commands, desde directorys que existen en todas las twigs. Sin embargo, todavía veo esto a veces:

 shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory 

El error anterior se imprime 4 o 5 veces, mientras que make procesa un par de líneas de comentarios. No he tenido suerte arreglando esto con mis pocos bashs. Mis búsquedas en Internet han arrojado muchos resultados con cosas como "Trabajar con twigs" o "Cambiar twigs", pero no hay nada que esté exactamente relacionado con esto. Como no puedo actualizar un file en una twig diferente, comprometerlo e insertlo sin cambiar realmente a esa twig (encontré la respuesta a esa pregunta), ¿qué opciones podría tener?

En resumen getcwd: cannot access parent directories: No such file or directory significa que estás tratando de hacer algunas cosas en un directory que ya no existe. Puede suceder de varias maneras, pero como mencionas cambiar de twig, ocurre algo como esto:

Tu repository tiene layout:

 repo_path/ +- a <- you're here \- b 

Pagará otra sucursal y su layout cambiará a:

 repo_path/ +- b \- c 'a' exists only in memory now, but you're still in it 

Ejecuta make – getcwd falla.

No puedo adivinar en qué punto sucede esto en sus scripts, pero, en general, puedo recomendarle que se cd en el directory raíz del repository antes de ejecutar los commands git. Si lo mantiene como base para todas las operaciones, será más difícil confundirse sobre el estado / location.

Una posible solución alternativa es evitar el pago por completo, lo que significa evitar tener que cambiar de sucursales … porque ya estarían desprotegidas.

Desde git 2.5, puedes usar múltiples treees de trabajo .
Haga uno para cada twig (usando git worktree add para el segundo tree de trabajo)
Y su secuencia de commands solo tiene que cd a la carpeta correcta para modificar el file y enviarlo a remoto. A continuación, vuelva al primer tree / twig de trabajo.