threads / patch / 41184

patchrebase: ignore failures from "gc --auto"

Subject: [PATCH] rebase: ignore failures from "gc --auto"

## tl;dr

4 messages between Jan 13, 2016 and Jan 13, 2016. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Jeff King· Jan 13, 2016, 18:47 UTC · lore

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
Jeff King· Jan 13, 2016, 18:50 UTC · re: Jeff King · lore

Re: [PATCH] rebase: ignore failures from "gc --auto"

On Wed, Jan 13, 2016 at 01:47:18PM -0500, Jeff King wrote:
> This bit me just now. The real blocker was "you have too many loose
> objects, run 'git prune'" left in the gc.log file.

Which was of course annoying in itself. I was running a scripted set of rebases, so even with this fix, my terminal got spammed with the "whoops, we can't auto-gc" message over and over.

The worst part is that when I looked at .git/objects, there were a lot of objects, but most of them could be cleaned up! I wonder if too_many_loose_objects() should take into account the prune time of the objects it finds. I also wonder how I got into that situation, since that check should come right _after_ we've finished running "gc". I wonder if I had two backgrounded auto-gc's racing or something.

-Peff
Rodrigo Campos· Jan 13, 2016, 19:40 UTC · re: Jeff King · lore

Re: [PATCH] rebase: ignore failures from "gc --auto"

On Wed, Jan 13, 2016 at 01:47:18PM -0500, Jeff King wrote:
Show 9 quoted lines
> 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"!).
Just curious, but do you mean "git rebase --abort" ?

Thanks, Rodrigo

Jeff King· Jan 13, 2016, 20:12 UTC · re: Rodrigo Campos · lore

Re: [PATCH] rebase: ignore failures from "gc --auto"

On Wed, Jan 13, 2016 at 04:40:11PM -0300, Rodrigo Campos wrote:
Show 12 quoted lines
> On Wed, Jan 13, 2016 at 01:47:18PM -0500, Jeff King wrote:
> > 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"!).
> 
> Just curious, but do you mean "git rebase --abort" ?
Yeah, sorry, I did mean "git rebase --abort".
-Peff

← back to recent threads