Ævar Arnfjörð Bjarmason wrote:
> Right. I know. What I mean is now I can (and do) use it to run 'git gc
> --auto' across our server fleet and see whether I have any of #3, or
> whether it's all #1 or #2. If there's nothing to do in #1 that's fine,
> and it just so happens that I'll run gc due to #2 that's also fine, but
> I'd like to see if gc really is stuck.
>
> This of course relies on them having other users / scripts doing normal
> git commands which would trigger previous 'git gc --auto' runs.
>
> I.e. with your change that command:
>
> git gc --auto
>
> Would change to something like:
>
> git gc --auto && ! test -e .git/gc.log
>
> Which, as noted is a bit of a nasty breaker of the encapsulation
That helps. What if we package up the "test -e .git/gc.log" bit
*without* having the side effect of running git gc --auto, so that you
can run
if ! git gc --detached-exit-code
then
... handle the error ...
fi
git gc --auto; # perhaps also with --detach
?
I'm not great at naming options, so the --detached-exit-code name is
bikesheddable. What I really mean to ask about is: what if the status
reporting goes in a separate command from running gc --auto?
Perhaps this reporting could also print the message from a previous
run, so you could write:
git gc --detached-status || exit
git gc --auto; # perhaps also passing --detach
(Names still open for bikeshedding.)
Thanks and hope that helps,
Jonathan
