On Thu, Jun 20 2019, Duy Nguyen wrote:
> On Thu, Jun 20, 2019 at 5:49 AM Ævar Arnfjörð Bjarmason
> wrote:
>>
>>
>> On Wed, Jun 19 2019, Jeff King wrote:
>>
>> > On Wed, Jun 19, 2019 at 08:01:55PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> > You could sort of avoid the problem here too wit
Jeff King writes:
> I think there may be room for both approaches. Yours fixes the repeated
> message in the more general case, but Duy's suggestion is the most
> efficient thing.
Yeah, not just the most efficient, but it is a low-hanging-fruit
that is very obvious.
> I agree that the "thousand
On Thu, Jun 20, 2019 at 12:49:32AM +0200, Ævar Arnfjörð Bjarmason wrote:
> We do it deterministically, when gc.auto thresholds et al are exceeded
> we kick one off without waiting for other stuff, if we can get the lock.
>
> I don't think this desire to just wait a bit until all the fetches are
>
On Thu, Jun 20, 2019 at 5:49 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Wed, Jun 19 2019, Jeff King wrote:
>
> > On Wed, Jun 19, 2019 at 08:01:55PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >
> >> > You could sort of avoid the problem here too with
> >> >
> >> > parallel 'git fetch --no-auto-gc {}'
On Wed, Jun 19 2019, Jeff King wrote:
> On Wed, Jun 19, 2019 at 08:01:55PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > You could sort of avoid the problem here too with
>> >
>> > parallel 'git fetch --no-auto-gc {}' ::: $(git remote)
>> > git gc --auto
>> >
>> > It's definitely simpler, but of
On Wed, Jun 19, 2019 at 08:01:55PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > You could sort of avoid the problem here too with
> >
> > parallel 'git fetch --no-auto-gc {}' ::: $(git remote)
> > git gc --auto
> >
> > It's definitely simpler, but of course we have to manually add
> > --no-auto-gc in
On Wed, Jun 19, 2019 at 07:51:00PM +0700, Duy Nguyen wrote:
> > Wheras mine fixes e.g. the same issue for:
> >
> > parallel 'git fetch {}' ::: $(git remote)
> >
> > Ditto for you running a "git" command and your editor running a
> > "fetch" at the same time.
>
> You could sort of avoid the pr
On Wed, Jun 19 2019, Duy Nguyen wrote:
> On Wed, Jun 19, 2019 at 5:26 PM Ævar Arnfjörð Bjarmason
> wrote:
>> This patch is part of a WIP branch I have that's a bit of a mess. It's
>> more-gc-detach-under-lock on github.com/avar/git.git. It doesn't apply
>> on master because it relies on some pr
On Wed, Jun 19, 2019 at 5:26 PM Ævar Arnfjörð Bjarmason
wrote:
> This patch is part of a WIP branch I have that's a bit of a mess. It's
> more-gc-detach-under-lock on github.com/avar/git.git. It doesn't apply
> on master because it relies on some previous test work, but for RFC
> purposes I figure
Continue the work started in c45af94dbc ("gc: run pre-detach
operations under lock", 2017-07-11).
Now we'll take the lock before we print out "Auto packing the
repository[...]", and we'll optimistically tolerate a locking failure
at that point instead of dying.
This (mostly) solves two issues:
10 matches
Mail list logo
