chris <j...@hotmail.com> writes: > 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.
Until the server completed the house keeping initiated under the control of the client and on behalf of its command. > But I do think we are on the same page otherwise in that the client > command is blocked until the server process completes. Sure. > 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. Except that there are _no_ asynchronously handled repository actions executed on behalf of a client action. If the repository owner decided to disable demand-based garbage collection in favor of a cron job, that's his call to make. It makes some sense when there are frequent and multiple accesses to the repository since it avoids getting denied access because of somebody _else_ triggering garbage collection predominantly when times are busiest. Usually you are not denied access by your _own_ garbage collection since the client waits until completion. It would be quite bad for scripting git if you constantly had to check after every action whether any associated garbage collection might or might not have completed. Note also that when pushing without a separate server process (like when pushing into a local repository), there is no other job which could be responsible for packing the repository rather than the one doing the push. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
