Duy Nguyen <pclouds <at> gmail.com> writes: > On Tue, Feb 4, 2014 at 12:13 PM, chris <jugg <at> hotmail.com> wrote: > > 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. > > > > 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. > > I agree it should not block the client. I think you can Ctrl-C "git > push" at this point without losing anything (data has already been > pushed at this point) but that's not a good advice to general cases. > Maybe we can do something at the server side to not block the client.. I'd like to avoid a Ctrl-C approach, but if an indication existed that assured me the push part of the operation had completed successfully, then that would be sufficient for when I'm impatient. > Another thing we could do is put "remote: " in front of these strings, > even in ssh case. They seem to confuse you (and me too) that things > happened locally. Yes, I would like to see more explicit clarity in what messages are coming from the server. That has always been a source of uncertainty for me with any remote git command output. Thanks for the patches and attention to this issue, I appreciate it. 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