¿Git devuelve códigos de error de retorno específicos?

86

Como errores de fusión o errores de rebase. ¿Tiene un código de error único?

git poymode
fuente

Respuestas:

56

Configuré una prueba para fallar. Esto es lo que conseguí:

$ git merge newbranch
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

$ echo $?
1

Git regresa 0cuando se fusiona correctamente, como se esperaba.

Chrisaycock
fuente
2
El problema es que los documentos de git merge(en 1.7.4 - kernel.org/pub/software/scm/git/docs/v1.7.4/git-merge.html ) solo mencionan el estado de devolución en un lugar (si usa "- -ff-only "y no puede hacer una confirmación de avance rápido, devuelve un valor distinto de cero; no dice explícitamente lo que se devuelve si todo funciona o si hubo un conflicto de fusión.
Matt Curtis
9
@Matt: Los comandos de Git son muy, muy buenos para devolver cero para el éxito y no cero (generalmente 1) de lo contrario. Siempre puede encadenar comandos de forma segura con &&; así es como se implementan sus pruebas.
Cascabel
17
Git no es bueno para devolver códigos de salida consistentes y sensibles. Por ejemplo, hacer git commit sin cambios saldrá con el código 1, pero diablos, no es un error.
pfalcon
3
De un comentario en el código fuente de builtin / merge.c: "El backend sale con 1 cuando los conflictos quedan por resolver, con 2 cuando no maneja la combinación dada en absoluto".
Mike
es git rebaseel mismo comportamiento?
osexp2003
60

En resumen, no. Verá el código de salida 1 para errores y 0 para éxito.

A partir de un grepping rápido de la fuente, hay algunos de los 127 y 128 esperados para sus propósitos específicos (comando no encontrado, errores ya reportados), y algunos códigos inusuales en algunos lugares, pero para errores comunes, es todo exit(1).

Cascabel
fuente
3
Esto es muy molesto para depurar sus ganchos de confirmación. ¿Cuál es el punto de incluso tener un código de salida en sus ganchos de git si una confirmación fallida siempre devolverá 1 en lugar de su código de salida del gancho?
Novato C
* Las aplicaciones nix devuelven un estado de 0 para un éxito total. La aplicación determina otros códigos de estado. Hay otros 255 códigos cuyos significados dependen de la aplicación. Consulte sus manpáginas para obtener más detalles.
shawnhcorey
3
@shawnhcorey El problema es que git no documenta sus códigos de error distintos de cero.
Ian Kemp
13

La ejecución git statusen un repositorio que no es de git devuelve 128, no 1, lo que es útil para determinar rápidamente si existe o no un repositorio de git.

Gus Shortz
fuente
6

El error 128, sin un mensaje de error de git, podría ser un problema general para "problema inesperado".

Recibí esto en operaciones que necesitaban modificar archivos bajo .git (por ejemplo, " git checkout -- myfile" para revertir un archivo modificado) por un usuario diferente. (En mi caso, " chmod -R og+w .git" lo solucionó; naturalmente, ¡no lo haga a menos que comprenda las implicaciones de seguridad para su caso!)

Darren Cook
fuente
6

git push --delete origin a_remote_tag_name

Esto devuelve 256 si la etiqueta no existe usando la versión de git 1.8.3.1

Sería bueno tener una lista consolidada de códigos de retorno específicos devueltos por cada comando y lo que indican. Esto también podría ayudar a evitar cambiar los significados del código de retorno (en los que pueden confiar los scripts de automatización).

manningr
fuente
2

Git 2.24 (Q4 2019) ilustra cómo los gitcomandos devuelven código.

Ver confirmar 50094ca , confirmar c1a6f21 , confirmar 854b5cb , confirmar dd2b6b6 , confirmar 6bd26f5 , confirmar c6ec6da , confirmar f2e2fa8 , confirmar 460609c , confirmar 92014b6 , confirmar 0ab74e9 , confirmar cb46c40 , confirmar b562a54 (27 de agosto de 2019), y confirmar fe de 20 por Denton Liu ( Denton-L) .
(Combinado por Junio ​​C Hamano - gitster- en el compromiso 1c6fc94 , 30 de septiembre de 2019)

t4014: deja de perder códigos de retorno de comandos git

Actualmente, hay dos formas en las que se pierden los códigos de retorno de los comandos de Git.

La primera forma es cuando un comando está en la parte superior de una tubería. En una tubería, solo se usa el código de retorno del último comando. Por lo tanto, todos los demás comandos tendrán sus códigos de retorno enmascarados.
Vuelva a escribir las tuberías para que no haya comandos de Git en sentido ascendente.

La otra forma es cuando un comando está en una subcapa de no asignación .
El código de retorno se perderá a favor del comando circundante.
Reescriba instancias de esto de modo que los comandos de Git se envíen a un archivo y los comandos circundantes solo llamen a subcapas con comandos que no sean de Git.

Entonces, en lugar de escribir:

git cat-file commit rebuild-1 | grep "^Side .* with .* backslash-n"

Tipo:

git cat-file commit rebuild-1 >actual &&
    grep "^Side .* with .* backslash-n" actual
VonC
fuente