On Wed, Jun 19, 2019 at 08:01:55PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > You could sort of avoid the problem here too with
> >
> > parallel 'git fetch --no-auto-gc {}' ::: $(git remote)
> > git gc --auto
> >
> > It's definitely simpler, but of course we have to manually add
> > --no-auto-gc in everywhere we need, so not quite as elegant.
> >
> > Actually you could already do that with 'git -c gc.auto=false fetch', I guess.
>
> The point of the 'parallel' example is to show disconnected git
> commands, think trying to run 'git' in a terminal while your editor
> asynchronously runs a polling 'fetch', or a server with multiple
> concurrent clients running 'gc --auto'.
>
> That's the question my RFC patch raises. As far as I can tell the
> approach in your patch is only needed because our locking for gc is
> buggy, rather than introduce the caveat that an fetch(N) operation won't
> do "gc" until it's finished (we may have hundreds, thousands of remotes,
> I use that for some more obscure use-cases) shouldn't we just fix the
> locking?
I think there may be room for both approaches. Yours fixes the repeated
message in the more general case, but Duy's suggestion is the most
efficient thing.
I agree that the "thousands of remotes" case means we might want to gc
in the interim. But we probably ought to do that deterministically
rather than hoping that the pattern of lock contention makes sense.
-Peff
