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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Kastrup <dak <at> gnu.org> writes:
> chris <jugg <at> 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.

I'm slightly confused by your response.  You say "client time" is not
consumed, but then go on to say that git server processes are synchronous to
avoid build up from batched client requests.  I expect you took "client
time" to have some specific technical meaning, while I simply meant that the
client command did not return until the server completed its own house keeping.

But I do think we are on the same page otherwise in that the client command
is blocked until the server process completes.

That said I would naively assume that a server side house keeping operation
that does not get invoked with every client request be a nice candidate for
asynchronous handling without any need to tell the client about it.

Regards,

Chris


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]