On Sat, May 24, 2014 at 4:40 AM, Junio C Hamano wrote:
> Duy, 9f673f94 (gc: config option for running --auto in background,
> 2014-02-08) turns to be not such a hot idea. Sure, if we kick it
> off background after doing something heavy, immediately before
> giving control back to the end-user, an
Adam Borowski writes:
> On Fri, May 23, 2014 at 02:40:41PM -0700, Junio C Hamano wrote:
>> Adam Borowski writes:
>> > It looks like the periodic auto-repack backgrounds itself when it shouldn't
>> > do so. This causes the command it has triggered as a part of to fail:
>>
>> Duy, 9f673f94 (gc:
On Fri, May 23, 2014 at 02:40:41PM -0700, Junio C Hamano wrote:
> Adam Borowski writes:
> > It looks like the periodic auto-repack backgrounds itself when it shouldn't
> > do so. This causes the command it has triggered as a part of to fail:
>
> Duy, 9f673f94 (gc: config option for running --aut
Adam Borowski writes:
> Hi guys!
>
> It looks like the periodic auto-repack backgrounds itself when it shouldn't
> do so. This causes the command it has triggered as a part of to fail:
Yikes. In the meantime, I think you can turn gc.autodetach off as a
workaround, e.g.
$ git config --glob
Hi guys!
It looks like the periodic auto-repack backgrounds itself when it shouldn't
do so. This causes the command it has triggered as a part of to fail:
==
[~/linux](master)$ git pull --rebase
remote: Counting objects: 455
5 matches
Mail list logo
