Re: [BUG] auto-repack exits prematurely, locking other processing out

[Duy Nguyen <pclouds@gmail.com>]

On Sat, May 24, 2014 at 4:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy, 9f673f94 (gc: config option for running --auto in background,
> 2014-02-08) turns to be not such a hot idea.  Sure, if we kick it
> off background after doing something heavy, immediately before
> giving control back to the end-user, and expect that the user will
> stay thinking without making new changes (i.e. read-only stuff like
> "git show" would be OK), then daemonize might be a great thing, but
> we forgot, while doing that commit, that long-running operations
> trigger the auto gc in the middle *and* they want it finish before
> they continue, as the purpose of gc is to help the performance
> during their further operation.

If by "long-running operations" you mean in a single process, it's my
first thought too but it looks like autogc is always called when the
process is all done and about to exit. The "git pull" case is
different because there's rebase after fetch. I see no easy way to
detect this kind of "middle of operation".

So we have two options: scripts should disable autogc before doing
things, a env variable would be more convenient than temporarily
updating gc.auto. Or we move "pack-refs" and "reflog expire" up,
before turning gc into a background task. Any locking will be
serialized this way. We could even go further to keep all but "repack"
in the background because it's "repack" that takes the longest time
(maybe "prune" coming close to second).
-- 
Duy