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

Reply via email to