{"thread":{"id":"41184","subject":"[PATCH] rebase: ignore failures from \"gc --auto\"","startedAt":"2016-01-13T18:47:18Z","lastAt":"2016-01-13T20:12:38Z","messageCount":4,"participants":["Jeff King","Rodrigo Campos"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"275954","messageId":"20160113184718.GA5647@sigill.intra.peff.net","threadId":"41184","inReplyTo":null,"subject":"[PATCH] rebase: ignore failures from \"gc --auto\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-01-13T18:47:18Z","receivedAt":"2016-01-13T18:47:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"After rebasing, we call \"gc --auto\" to clean up if we\ncreated a lot of loose objects. However, we do so inside an\n&&-chain. If \"gc --auto\" fails (e.g., because a previous\nbackground gc blocked us by leaving \"gc.log\" in place),\nthen:\n\n  1. We will fail to clean up the state directory, leaving\n     the user stuck in the rebase forever (even \"git am\n     --abort\" doesn't work, because it calls \"gc --auto\"!).\n\n  2. In some cases, we may return a bogus exit code from\n     rebase, indicating failure when everything except the\n     auto-gc succeeded.\n\nWe can fix this by ignoring the exit code of \"gc --auto\".\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nThis bit me just now. The real blocker was \"you have too many loose\nobjects, run 'git prune'\" left in the gc.log file.\n\nIt looks like this is the only \"gc --auto\" we call from a shell script,\nand all of the C callers already ignore the exit code. So no other spots\nneed a similar fix.\n\n git-rebase.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex af7ba5f..cf60c43 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -176,7 +176,7 @@ You can run \"git stash pop\" or \"git stash drop\" at any time.\n \n finish_rebase () {\n \tapply_autostash &&\n-\tgit gc --auto &&\n+\t{ git gc --auto || true; } &&\n \trm -rf \"$state_dir\"\n }\n \n-- \n2.7.0.242.gdeece69\n"},{"id":"275955","messageId":"20160113185052.GA5786@sigill.intra.peff.net","threadId":"41184","inReplyTo":"20160113184718.GA5647@sigill.intra.peff.net","subject":"Re: [PATCH] rebase: ignore failures from \"gc --auto\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-01-13T18:50:52Z","receivedAt":"2016-01-13T18:50:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 13, 2016 at 01:47:18PM -0500, Jeff King wrote:\n\n> This bit me just now. The real blocker was \"you have too many loose\n> objects, run 'git prune'\" left in the gc.log file.\n\nWhich was of course annoying in itself. I was running a scripted set of\nrebases, so even with this fix, my terminal got spammed with the\n\"whoops, we can't auto-gc\" message over and over.\n\nThe worst part is that when I looked at .git/objects, there were a lot\nof objects, but most of them could be cleaned up! I wonder if\ntoo_many_loose_objects() should take into account the prune time of the\nobjects it finds. I also wonder how I got into that situation, since\nthat check should come right _after_ we've finished running \"gc\". I\nwonder if I had two backgrounded auto-gc's racing or something.\n\n-Peff\n"},{"id":"275969","messageId":"20160113194011.GD20764@sdfg.com.ar","threadId":"41184","inReplyTo":"20160113184718.GA5647@sigill.intra.peff.net","subject":"Re: [PATCH] rebase: ignore failures from \"gc --auto\"","fromName":"Rodrigo Campos","fromEmail":"rodrigo@sdfg.com.ar","sentAt":"2016-01-13T19:40:11Z","receivedAt":"2016-01-13T19:40:11Z","isPatch":true,"sender":{"key":"rodrigo@sdfg.com.ar","avatar":null},"body":"On Wed, Jan 13, 2016 at 01:47:18PM -0500, Jeff King wrote:\n> After rebasing, we call \"gc --auto\" to clean up if we\n> created a lot of loose objects. However, we do so inside an\n> &&-chain. If \"gc --auto\" fails (e.g., because a previous\n> background gc blocked us by leaving \"gc.log\" in place),\n> then:\n> \n>   1. We will fail to clean up the state directory, leaving\n>      the user stuck in the rebase forever (even \"git am\n>      --abort\" doesn't work, because it calls \"gc --auto\"!).\n\nJust curious, but do you mean \"git rebase --abort\" ?\n\n\n\n\nThanks,\nRodrigo\n"},{"id":"275970","messageId":"20160113201238.GA6978@sigill.intra.peff.net","threadId":"41184","inReplyTo":"20160113194011.GD20764@sdfg.com.ar","subject":"Re: [PATCH] rebase: ignore failures from \"gc --auto\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-01-13T20:12:38Z","receivedAt":"2016-01-13T20:12:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 13, 2016 at 04:40:11PM -0300, Rodrigo Campos wrote:\n\n> On Wed, Jan 13, 2016 at 01:47:18PM -0500, Jeff King wrote:\n> > After rebasing, we call \"gc --auto\" to clean up if we\n> > created a lot of loose objects. However, we do so inside an\n> > &&-chain. If \"gc --auto\" fails (e.g., because a previous\n> > background gc blocked us by leaving \"gc.log\" in place),\n> > then:\n> > \n> >   1. We will fail to clean up the state directory, leaving\n> >      the user stuck in the rebase forever (even \"git am\n> >      --abort\" doesn't work, because it calls \"gc --auto\"!).\n> \n> Just curious, but do you mean \"git rebase --abort\" ?\n\nYeah, sorry, I did mean \"git rebase --abort\".\n\n-Peff\n"}]}