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