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.
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