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
tsuna <tsuna...@gmail.com> writes:
> While investigating a hung job in our CI system today, I think I found
> a deadlock in git-remote-http
> ...
> Here PID 27319 (git fetch-pack) is stuck reading on stdin, while its
> parent, PID 27317 (git-remote-http) is stuck reading on
-pack --stateless-rpc --stdin
--lock-pack --include-tag --thin --no-progress --depth=2147483647
http://gerrit/arista/
Here PID 27319 (git fetch-pack) is stuck reading on stdin, while its
parent, PID 27317 (git-remote-http) is stuck reading on its child’s
stdout. Nothing has moved for like 2h, it’s
../../../arista fetch --unshallow
jenkins 27317 0.0 0.0 169608 10916 ?S19:30 0:00 |
\_ git-remote-http origin http://gerrit/arista
jenkins 27319 0.0 0.0 24160 8260 ?S19:30 0:00 |
\_ git fetch-pack --stateless-rpc --stdin
--lock-pack
- separate URLs like file (which are local)
from URLs like host:repo which should use ssh
Add the new parameter --diag-url to git fetch-pack,
which prints the value for protocol, host and path to stderr and exits.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
builtin/fetch-pack.c | 14
not
break the repository' '
git fsck
)
'
+check_prot_path() {
+ actual
There is no need to truncate actual here, ...
+ (git fetch-pack --diag-url $1 21 1stdout) | grep -v host= actual
... because it will be overwritten in this line anyway.
+ echo Diag
Torsten Bögershausen tbo...@web.de writes:
Subject: Re: [PATCH v6 05/10] git fetch-pack: Add --diag-url
s/Add/add/ please.
The main purpose is to trace the URL parser called by git_connect() in
connect.c
The main features of the parser can be listed as this:
- parse out host and path
- seperate URLs like file (which are local)
from URLs like host:repo which should use ssh
Add the new parameter --diag-url to git fetch-pack,
which prints the value for protocol, host and path to stderr and exits.
---
builtin/fetch-pack.c | 14 ++---
connect.c | 27
Torsten Bögershausen tbo...@web.de writes:
git fetch-pack allows [host:]directory to point out the source
repository.
Use the term repository, which is already used in git fetch or git pull
to describe URLs supported by Git.
Sign-off?
---
Documentation/git-fetch-pack.txt | 15
On 2013-11-11 18.44, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
git fetch-pack allows [host:]directory to point out the source
repository.
Use the term repository, which is already used in git fetch or git pull
to describe URLs supported by Git.
Sign-off?
Sorry
Torsten Bögershausen tbo...@web.de writes:
On 2013-11-11 18.44, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
git fetch-pack allows [host:]directory to point out the source
repository.
Use the term repository, which is already used in git fetch or git
pull
to describe
git fetch-pack allows [host:]directory to point out the source
repository.
Use the term repository, which is already used in git fetch or git pull
to describe URLs supported by Git.
---
Documentation/git-fetch-pack.txt | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff
Hello,
We are using git with the smart HTTP protocol. We are seeing the client
freeze with Jenkins poll. It stops the continuous build which is a bit
of a pain. It happens with the latest release 1.8.0 on the client side.
The server is using 1.7.0.4.
On the server we are seeing the following
On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis ivan.ka...@googlemail.com wrote:
We are using git with the smart HTTP protocol. We are seeing the client
freeze with Jenkins poll. It stops the continuous build which is a bit
of a pain. It happens with the latest release 1.8.0 on the client side.
Hi Shawn,
Thanks for the quick reply.
Shawn Pearce spea...@spearce.org wrote:
On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis ivan.ka...@googlemail.com wrote:
On the server we are seeing the following error message:
Upgrade your server.
OK we'll look into it. I have a question: will a 1.8
On Wed, Nov 28, 2012 at 9:25 AM, Ivan Kanis ivan.ka...@googlemail.com wrote:
Shawn Pearce spea...@spearce.org wrote:
On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis ivan.ka...@googlemail.com
wrote:
On the server we are seeing the following error message:
Upgrade your server.
OK we'll look
27 matches
Mail list logo