Browse Source
We might wonder why our && chain check does not catch this case: The && chain check uses a strange exit code with the expectation that the second or later part of a broken && chain would not exit with this particular code. This expectation does not work in this case because __git_ps1, being the first command in the second part of the broken && chain, records the current exit code, does its work, and finally returns to the caller with the recorded exit code. This fools our && chain check. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>maint
Johannes Sixt
8 years ago
committed by
Junio C Hamano
1 changed files with 1 additions and 1 deletions
Loading…
Reference in new issue