Re: [PATCH] gc: save log from daemonized gc --auto and print it next time

[Junio C Hamano <gitster@pobox.com>]

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> 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?