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

From: Duy Nguyen <pclouds@gmail.com>
Date: May 24, 2014, 01:26 UTC
Message-ID: <CACsJy8BfziZ7ciyKL0+X3rT9EfH_0E8nKNu9mTb_WSeTYWix_Q@mail.gmail.com>
In-Reply-To: <xmqqy4xsgome.fsf@gitster.dls.corp.google.com>

On Sat, May 24, 2014 at 4:40 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> 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