Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > While commit 9f673f9 (gc: config option for running --auto in > background - 2014-02-08) helps reduce some complaints about 'gc > --auto' hogging the terminal, it creates another set of problems. > > The latest in this set is, as the result of daemonizing, stderr is > closed and all warnings are lost. This warning at the end of cmd_gc() > is particularly important because it tells the user how to avoid "gc > --auto" running repeatedly. Because stderr is closed, the user does > not know, naturally they complain about 'gc --auto' wasting CPU. > > Besides reverting 9f673f9 and looking at the problem from another > angle, we could save the stderr in $GIT_DIR/gc.log. Next time, 'gc > --auto' will print the saved warnings, delete gc.log and exit. I wonder what this buys us if multiple auto-gc's are triggered because the user is running a long svn import or something similar. > diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh > index 63194d8..54bc9c4 100755 > --- a/t/t6500-gc.sh > +++ b/t/t6500-gc.sh > @@ -30,4 +30,24 @@ test_expect_success 'gc -h with invalid configuration' ' > test_i18ngrep "[Uu]sage" broken/usage > ' > > +test_expect_success !MINGW 'gc --auto and logging' ' > + git init abc && > + ( > + cd abc && > + # These create blobs starting with the magic number "17" > + for i in 901 944; do There are numbers smaller than these, like 263 and 410 ;-) > + echo $i >test && git hash-object -w test >/dev/null "hash-object --stdin"? > + done && > + git config gc.auto 1 && test_config? > + LANG=C git gc --auto && > + sleep 1 && # give it time to daemonize > + while test -f .git/gc.pid; do sleep 1; done && Yuck... > + grep "too many unreachable loose objects" .git/gc.log && > + LANG=C git gc --auto 2>error && > + grep skipped error && > + grep "too many unreachable loose objects" error && > + ! test -f .git/gc.log > + ) > +' For that "17/ has very many loose objects that are still young and unreachable" issue, I wonder if the right solution is somehow to flag the repository and prevent "gc --auto" from running until the situation improves. "I checked at this time and found too many in 17/"; upon finding that flag file (with a timestamp), if there are new files in 17/ or if there are other reasons to do a gc (perhaps there are too many packfiles to be consolidated?), then do the gc but otherwise quite silently before spending too many cycles on it, or something along that line? -- 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