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.
> 
> This string only appears in versions before 1.8.0. It's longer after 1.8.0.
> 
> > To ssh://git <at> my.server.com/my_project
> >    3560275..f508080  next -> next
> > $ git config gc.auto
> > 0
> > $ git config gc.autopacklimit
> > 0
> > $ git --version
> > git version 1.8.5.3
> 
> but your client is after 1.8.0 so the string printed above is from the
> server side. "git config gc.auto" here does not matter. Run that
> command again on my.server.com.

Ok, so I can understand if the message is from the server.  I'll chalk up
never noticing it before to someone else always being the lucky one to
trigger it.

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.

> > So my question is, should gc.auto = 0 disable auto-packing from occurring on
> > git push and other non-gc commands?
> 
> Yes it should.

Thanks for the confirmation.

Regards,

Chris



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