Podobnie jak błędy scalania lub błędy ponownego bazowania. Czy ma unikalny kod błędu?
Odpowiedzi:
Ustawiłem test na niepowodzenie. Oto co mam:
$ 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 zwraca, 0gdy scala się poprawnie, zgodnie z oczekiwaniami.
&&; w ten sposób wdrażane są ich testy.
git rebaseto samo zachowanie?
Krótko mówiąc, nie. Zobaczysz kod zakończenia 1 dla błędów i 0 dla sukcesu.
Z szybkiego grepowania źródła wynika, że jest kilka oczekiwanych 127 i 128 dla ich konkretnych celów (polecenie nie zostało znalezione, błędy już zgłoszone) i kilka nietypowych kodów w kilku miejscach, ale dla błędów run of the mill jest to wszystko exit(1).
manstrony, aby uzyskać szczegółowe informacje.
Uruchomienie git statusna repozytorium non-git zwraca 128, a nie 1, co jest pomocne w szybkim określeniu, czy repozytorium git istnieje, czy nie.
Błąd 128, bez komunikatu o błędzie z gita, może być typowym przykładem „nieoczekiwanego problemu”.
Otrzymywałem to w przypadku operacji, które wymagały modyfikacji plików w .git (np. „ git checkout -- myfile” W celu przywrócenia zmodyfikowanego pliku) przez innego użytkownika. (W moim przypadku " chmod -R og+w .git" to naprawiłem; oczywiście nie rób tego, chyba że rozumiesz wpływ na bezpieczeństwo twojego przypadku!)
git push --delete origin a_remote_tag_name
Zwraca 256, jeśli tag nie istnieje przy użyciu wersji git 1.8.3.1
Byłoby miło mieć skonsolidowaną listę konkretnych kodów powrotu zwracanych przez każde polecenie i to, co one wskazują. Może to również pomóc w zapobieganiu zmianie znaczenia kodu powrotu (na którym mogą polegać skrypty automatyzacji).
Git 2.24 (Q4 2019) ilustruje, jak gitpolecenia zwracają kod.
Zobacz zatwierdzenie 50094ca , zatwierdzenie c1a6f21 , zatwierdzenie 854b5cb , zatwierdzenie dd2b6b6 , zatwierdzenie 6bd26f5 , zatwierdzenie c6ec6da , zatwierdzenie f2e2fa8 , zatwierdzenie 460609c , zatwierdzenie 92014b6 , zatwierdzenie 0ab74e9 , zatwierdzenie cb46c40 , zatwierdzenie b562a54 (27 sierpnia 2019 r.) I 20 fe commit użytkownika Denton Liu ( Denton-L) .
(Scalone przez Junio C Hamano - gitster- w zatwierdzeniu 1c6fc94 , 30 września 2019)
t4014: przestań tracić kody powrotu poleceń git
Obecnie istnieją dwa sposoby utraty kodów powrotnych poleceń Git.
Pierwszy sposób polega na tym, że polecenie znajduje się w górnej części potoku. W potoku używany jest tylko kod powrotu ostatniego polecenia. W ten sposób wszystkie inne polecenia będą miały maskowane kody powrotu.
Przepisz potoki, aby nie było żadnych poleceń Gita.Innym sposobem jest sytuacja, gdy polecenie znajduje się w podpowłoce bez przypisania .
Kod powrotu zostanie utracony na rzecz polecenia otaczającego.
Przepisz instancje tego w taki sposób, że polecenia Git wysyłane do pliku, a polecenia otaczające wywołują tylko podpowłoki z poleceniami spoza Git.
Więc zamiast pisać:
git cat-file commit rebuild-1 | grep "^Side .* with .* backslash-n"
Rodzaj:
git cat-file commit rebuild-1 >actual &&
grep "^Side .* with .* backslash-n" actual
git merge(w 1.7.4 - kernel.org/pub/software/scm/git/docs/v1.7.4/git-merge.html ) wspominają o statusie zwrotu tylko w jednym miejscu (jeśli używasz "- -ff-only "i nie może wykonać szybkiego zatwierdzenia do przodu, zwraca wartość niezerową - nie informuje wyraźnie, co jest zwracane, jeśli wszystko działa lub jeśli wystąpił konflikt scalania.