Hi,
Thank you for merging!
Takuto
2017-11-28 20:27 GMT+09:00 Johannes Schindelin :
> Hi,
>
> On Tue, 28 Nov 2017, Takuto Ikuta wrote:
>
>> As long as this PR is included in next Git for Windows release, I
>> won't suffer from slow git fetch.
>>
Hi,
On Tue, 28 Nov 2017, Takuto Ikuta wrote:
> As long as this PR is included in next Git for Windows release, I
> won't suffer from slow git fetch.
> https://github.com/git-for-windows/git/pull/1372
>
> But I sent you 2 PRs to follow right way.
>
Hi Johannes,
As long as this PR is included in next Git for Windows release, I
won't suffer from slow git fetch.
https://github.com/git-for-windows/git/pull/1372
But I sent you 2 PRs to follow right way.
https://github.com/git-for-windows/git/pull/1379
Hi Junio,
On Tue, 28 Nov 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > My current plan is to release a new Git for Windows version on Wednesday,
> > to allow for a new cURL version to be bundled.
>
> Is this an updated 2.15.0 or are you planning
Johannes Schindelin writes:
> My current plan is to release a new Git for Windows version on Wednesday,
> to allow for a new cURL version to be bundled.
Is this an updated 2.15.0 or are you planning to package 2.15.1? I
am asking because you earlier asked me to hold
Hi,
On Mon, 27 Nov 2017, Takuto Ikuta wrote:
> 2017-11-27 13:53 GMT+09:00 Junio C Hamano :
> > Jeff King writes:
> >
> >>> The 5-patch series that contains the same change as this one is
> >>> cooking and will hopefully be in the released version before the end
On Mon, Nov 27, 2017 at 01:53:34PM +0900, Junio C Hamano wrote:
> > I'd be curious if the 5th patch there provides an additional speedup for
> > Takuto's case.
>
> Indeed, it is a very good point.
>
> IIUC, the 5th one is about fetching tons of refs that you have never
> seen, right? If a
2017-11-27 13:53 GMT+09:00 Junio C Hamano :
> Jeff King writes:
>
>>> cf.
>>> https://public-inbox.org/git/20171120202920.7ppcwmzkxifyw...@sigill.intra.peff.net/
>>
>> It's funny that we'd get two patches so close together. AFAIK the
>> slowness here has been
Jeff King writes:
>> cf.
>> https://public-inbox.org/git/20171120202920.7ppcwmzkxifyw...@sigill.intra.peff.net/
>
> It's funny that we'd get two patches so close together. AFAIK the
> slowness here has been with us for years, and I just happened to
> investigate it recently.
>
>>
On Mon, Nov 27, 2017 at 01:35:35PM +0900, Junio C Hamano wrote:
> Takuto Ikuta writes:
>
> > diff --git a/fetch-pack.c b/fetch-pack.c
> > index 008b25d3db087..0184584e80599 100644
> > --- a/fetch-pack.c
> > +++ b/fetch-pack.c
> > @@ -716,7 +716,7 @@ static int
Takuto Ikuta writes:
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 008b25d3db087..0184584e80599 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -716,7 +716,7 @@ static int everything_local(struct fetch_pack_args *args,
> for (ref = *refs; ref; ref = ref->next)
Do not call prepare_packed_git for every refs.
In fetch-pack, git list ups entries in .git/objects/pack
directory for each refs.
Such behavior makes git fetch-pack slow for the repository having the
large number of refs, especially for windows.
For chromium repository, having more than 30
12 matches
Mail list logo