After rebasing, we call "gc --auto" to clean up if we
created a lot of loose objects. However, we do so inside an
&&-chain. If "gc --auto" fails (e.g., because a previous
background gc blocked us by leaving "gc.log" in place),
then:
1. We will fail to clean up the state directory, leaving
the user stuck in the rebase forever (even "git am
--abort" doesn't work, because it calls "gc --auto"!).
2. In some cases, we may return a bogus exit code from
rebase, indicating failure when everything except the
auto-gc succeeded.
We can fix this by ignoring the exit code of "gc --auto".
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
This bit me just now. The real blocker was "you have too many loose
objects, run 'git prune'" left in the gc.log file.
It looks like this is the only "gc --auto" we call from a shell script,
and all of the C callers already ignore the exit code. So no other spots
need a similar fix.
git-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index af7ba5f..cf60c43 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -176,7 +176,7 @@ You can run "git stash pop" or "git stash drop" at any time.
finish_rebase () {
apply_autostash &&
- git gc --auto &&
+ { git gc --auto || true; } &&
rm -rf "$state_dir"
}
--
2.7.0.242.gdeece69
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html