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.
>> https://github.com/git-for-windows/git/pull/1372
>>
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.
> https://github.com/git-for-windows/git/pull/1379
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
https://github.com/git-for-windows/git/pull/
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 to package 2.15.1?
If there i
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 2.15.1 while you were
away l
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
> >>> of the year.
> >>
> >> I'd b
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 repos
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 with us for years, and I just happene
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.
>
>> The 5-patch ser
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 everything_local(struct fetch_pack_
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) {
> s
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 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 its child’s
> stdout.
-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öge
llow fetch with tags does not
> break the repository' '
> git fsck
> )
> '
> +check_prot_path() {
> + > actual &&
There is no need to truncate actual here, ...
> + (git fetch-pack --diag-url "$1" 2>&1 1>
Torsten Bögershausen 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 h
- 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 +
Torsten Bögershausen writes:
> On 2013-11-11 18.44, Junio C Hamano wrote:
>> Torsten Bögershausen writes:
>>
>>> "git fetch-pack" allows [:] to point out the source
>>> repository.
>>> Use the term , which is already used in "git fetch&
On 2013-11-11 18.44, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> "git fetch-pack" allows [:] to point out the source
>> repository.
>> Use the term , which is already used in "git fetch" or "git pull"
>> to describe UR
Torsten Bögershausen writes:
> "git fetch-pack" allows [:] to point out the source
> repository.
> Use the term , which is already used in "git fetch" or "git pull"
> to describe URLs supported by Git.
Sign-off?
> ---
> Documentation/git-fetch
"git fetch-pack" allows [:] to point out the source
repository.
Use the term , 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(+)
On Wed, Nov 28, 2012 at 9:25 AM, Ivan Kanis wrote:
> Shawn Pearce wrote:
>
>> On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis
>> 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 server still s
Hi Shawn,
Thanks for the quick reply.
Shawn Pearce wrote:
> On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis 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 server still serve
1.7 git client?
> So
On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis 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.
> The server is using 1.7.
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 erro
>>>>> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> Well, I'm not working on it, but tested patches...
Prodded by the hint...
The git-fetch-pack command used internally by git-fetch-script
which in turn is used by git-clone-script re
Ok,
I've written a "git-fetch-pack" along the lines I outlined a few days
ago, ie the person doing the fetching ends up listing the commits it has,
and then both ends negotiate the missing objects.
It's probably buggy in many ways, but I actually used it to fetch the last
29 matches
Mail list logo
