Æ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
