example - git-apply
¿Por qué git-bisect debe ejecutarse desde el directorio de nivel superior del árbol de trabajo? (2)
El proceso de bisección necesita revisar diferentes revisiones de su proyecto. Si una revisión particular no contiene la carpeta actual, entonces la carpeta actual será eliminada.
En ese caso, tu shell podría terminar sentado en una carpeta que ya no está en el sistema de archivos. Git no podrá encontrar la carpeta .git
del nivel .git
y, por lo tanto, el proceso bisect no podrá continuar sin intervención.
Una demostración:
$ git rev-parse --show-toplevel
/path/to/project
$ mkdir tmp
$ cd tmp
$ rmdir ../tmp
$ git rev-parse --show-toplevel
fatal: Unable to read current working directory: No such file or directory
Por supuesto, este mismo problema puede ocurrir al hacer git checkout
, y puede solucionarse fácilmente después del hecho, por ejemplo, con cd ..
(willoller explica por qué funciona en la shell pero no en git).
Pero como la bisección es un proceso , tiene sentido evitar esta situación antes de comenzar, especialmente si queremos usar automatización como git bisect run
.
Si uno intenta ejecutar cualquiera de los comandos git-bisect desde cualquier lugar que no sea el directorio raíz del repositorio, se le dice a uno:
Debe ejecutar este comando desde el nivel superior del árbol de trabajo.
¿Porqué es eso? No conozco ningún otro comando git que tenga este requisito, y no veo ninguna razón obvia para que bisect deba ser especial. La página del manual tampoco hace mención de esta restricción.
Realmente no es un gran problema. Estoy mayormente curioso.
Viendo algunos compromisos en el proyecto, veo uno de Marcel M. Cary ([email protected])
Dice en un compromiso (sucede que se trata de git-pull, pero creo que es relevante)
"git pull" falla porque los shells POSIX tienen una noción de directorio de trabajo actual que es diferente de getcwd (). El shell almacena esta ruta en PWD. Como resultado, "cd ../" se puede interpretar de manera diferente en un script de shell que en chdir ("../") en un programa en C. El shell interpreta "../" esencialmente eliminando el último componente de ruta textual de PWD, mientras que C chdir () sigue el enlace ".." en el directorio actual del sistema de archivos. Cuando PWD es un enlace simbólico, estos son destinos diferentes. Como resultado, los comandos C de Git encuentran el árbol de trabajo de nivel superior correcto y los scripts de shell no.
https://github.com/git/git/commit/08fc0608657ee91bc85276667804c36a93138c7d
Así que diría que parte de la razón es porque git-bisect es un script de shell en el que no se puede confiar para encontrar el nivel superior por sí solo (cuando están implicados los enlaces simbólicos).