O git retorna códigos de erro de retorno específicos?

86

Como erros de mesclagem ou erros de rebase. Ele tem um código de erro exclusivo?

git

— poymode
fonte

56

Eu configurei um teste para falhar. Isso é o que eu tenho:

$ 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 retorna 0quando se mescla corretamente, como esperado.

— chrisaycock
fonte

2

O problema é que os documentos para git merge(em 1.7.4 - kernel.org/pub/software/scm/git/docs/v1.7.4/git-merge.html ) apenas mencionam o status de retorno em um lugar (se você usar "- -ff-only "e não pode fazer um commit de avanço rápido, ele retorna diferente de zero - não diz explicitamente o que é retornado se tudo funcionar ou se houve um conflito de fusão.

— Matt Curtis

9

@Matt: Os comandos do Git são muito, muito bons em retornar zero para sucesso e diferente de zero (geralmente 1) caso contrário. Você sempre pode encadear comandos com segurança com &&; é assim que seus testes são implementados.

— Cascabel

17

Git não é bom para retornar códigos de saída consistentes e razoáveis. Por exemplo, fazer git commit sem alterações vai sair com o código 1, mas, diabos, não é um erro.

— falcão

3

De um comentário no código-fonte de builtin / merge.c: "O back-end sai com 1 quando os conflitos são deixados para serem resolvidos, com 2 quando ele não controla a mesclagem fornecida."

— Mike

é git rebaseo mesmo comportamento?

— osexp2003

60

Resumindo, não. Você verá o código de saída 1 para erros e 0 para sucesso.

A partir de um rápido grep da fonte, existem alguns dos 127 e 128 esperados para seus propósitos específicos (comando não encontrado, erros já relatados) e alguns códigos incomuns em alguns lugares, mas para erros de run of the mill, é tudo exit(1).

— Cascabel
fonte

3

Isso é extremamente irritante para depurar seus ganchos de commit. Qual é o ponto de até mesmo ter um código de saída em seus ganchos git se um commit com falha vai sempre retornar 1 em vez de seu código de saída de gancho.

— Iniciante C,

* Os aplicativos nix retornam um status de 0 para sucesso total. Outros códigos de status são determinados pelo aplicativo. Existem 255 outros códigos cujos significados dependem do aplicativo. Veja suas manpáginas para detalhes.

— shawnhcorey

3

@shawnhcorey O problema é que git não documenta seus códigos de erro diferentes de zero.

— Ian Kemp

13

A execução git statusem um repo não git retorna 128, não 1, o que é útil para determinar rapidamente se um repo git existe ou não.

— Gus Shortz
fonte

6

O erro 128, sem nenhuma mensagem de erro do git, pode ser uma solução geral para "problema inesperado".

Eu estava recebendo isso em operações que precisavam modificar arquivos em .git (por exemplo, " git checkout -- myfile" para reverter um arquivo modificado) por um usuário diferente. (No meu caso, " chmod -R og+w .git" corrigiu; naturalmente, não faça isso a menos que você entenda as implicações de segurança para o seu caso!)

— Darren Cook
fonte

6

git push --delete origin a_remote_tag_name

Isso retorna 256 se a tag não existe usando a versão git 1.8.3.1

Seria bom ter uma lista consolidada de códigos de retorno específicos retornados por cada comando e o que eles indicam. Isso também pode ajudar a evitar a alteração dos significados do código de retorno (nos quais os scripts de automação podem depender).

— manningr
fonte

2

O Git 2.24 (quarto trimestre de 2019) ilustra como os gitcomandos retornam o código.

Ver commit 50094ca , commit c1a6f21 , commit 854b5cb , commit dd2b6b6 , commit 6bd26f5 , commit c6ec6da , commit f2e2fa8 , commit 460609c , commit 92014b6 , commit 0ab74e9 , commit cb46c40 , commit b562a54 (27 de agosto de 2019) e commit b562a54 (27 de agosto de 2019) por Denton Liu ( Denton-L) .
^{(Incorporado por Junio C Hamano - gitster- no commit 1c6fc94 , 30 de setembro de 2019)}

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

Atualmente, existem duas maneiras em que os códigos de retorno dos comandos Git são perdidos.

A primeira maneira é quando um comando está na parte superior de um tubo. Em um pipe, apenas o código de retorno do último comando é usado. Assim, todos os outros comandos terão seus códigos de retorno mascarados.
Reescreva os canais para que não haja comandos Git upstream.

A outra maneira é quando um comando está em um subshell sem atribuição .
O código de retorno será perdido em favor do comando circundante.
Reescreva as instâncias disso de forma que os comandos Git saiam para um arquivo e os comandos adjacentes apenas chamem subshells com comandos não-Git.

Então, em vez de escrever:

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
fonte