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@peff.net> --- 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(-)
Show changes to git-rebase.sh +1 −1
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