Re: bug? git push triggers auto pack when gc.auto = 0

[David Kastrup <dak@gnu.org>]

chris <jugg@hotmail.com> writes:

> Duy Nguyen <pclouds <at> gmail.com> writes:
>> On Tue, Feb 4, 2014 at 9:20 AM, chris <jugg <at> hotmail.com> wrote:
>> > $ git push origin next
>> > Counting objects: 56, done.
>> > Delta compression using up to 4 threads.
>> > Compressing objects: 100% (9/9), done.
>> > Writing objects: 100% (9/9), 895 bytes | 0 bytes/s, done.
>> > Total 9 (delta 8), reused 0 (delta 0)
>> > Auto packing the repository for optimum performance.

> However, I question why I should even care about this message?  I'm going to
> assume that simply it is a lengthy synchronous operation that someone felt
> deserved some verbosity to why the client push action is taking longer than
> it should.  Yet that makes me question why I'm being penalized for this
> server side operation.  My client time should not be consumed for server
> side house keeping.

Your "client time" is not consumed: this is not a busy wait.  Git server
processes are synchronous: they are initiated and completed under the
control of a client.  That means that if you run a batch script
executing a number of commands in a client, it will not saturate the
server with half-finished processes and/or will refuse to honor requests
because the repository is locked.

> An obvious fix is to disable gc on the server and implement a cron job
> for the house keeping task.  However, as often the case one does not
> have control over the server, so it is unfortunate that git has this
> server side house keeping as a blocking operation to a client action.

_Any_ git operation is "blocking" the respective initiating client.

>> > So my question is, should gc.auto = 0 disable auto-packing from occurring on
>> > git push and other non-gc commands?
>> 
>> Yes it should.
>
> Thanks for the confirmation.

And indeed, there is no autopacking occuring on your site when doing git
push.  The server administrator will be rather glad that the clients'
configuration variables don't affect his server's operation.

-- 
David Kastrup