Git status delay

Git status delay

[Richard H Lee]

I have an issue with git where it hangs for 10 to 20 seconds on several 
commands, including "git status". For me this is reproducible on a fresh 
install of Cygwin x64 in Windows 7.

I get the feeling I am doing something wrong on my end as "git status" 
is a very commonly used command, yet I see no mentions of this on the 
Cygwin mailing list.

Using gdb I can see git hang in the function validate_headref on an 
lstat call. validate_headref pretty much does what it says and validates 
the HEAD reference file. validate_headref is called multiple times for 
different candidate paths for the HEAD reference file, e.g. ".git/HEAD" 
etc. For some reason the path "//HEAD" is checked and this is causing a 
delay. Paths starting with "//" are treated in Cygwin as CIFS paths and 
the delay comes from the timeout when Windows tries to resolve the 
hostname "HEAD" to a server.

Subsequent executions of "git status" return immediately as I guess the 
resolution of "HEAD" as a hostname is cached.

I don't recall having this problem previously.

Does anyone else experience this issue?


Richard

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[Richard H Lee]

Can also confirm this on Windows 10.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[cyg Simple]

On 11/20/2017 5:03 AM, Richard H Lee wrote:
> Can also confirm this on Windows 10.
> 

I don't see an issue.  Maybe your environment or some BLODA app.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[Andrey Repin]

Greetings, Richard H Lee!

> I have an issue with git where it hangs for 10 to 20 seconds on several 
> commands, including "git status". For me this is reproducible on a fresh 
> install of Cygwin x64 in Windows 7.

> I get the feeling I am doing something wrong on my end as "git status" 
> is a very commonly used command, yet I see no mentions of this on the 
> Cygwin mailing list.

> Using gdb I can see git hang in the function validate_headref on an 
> lstat call. validate_headref pretty much does what it says and validates 
> the HEAD reference file. validate_headref is called multiple times for 
> different candidate paths for the HEAD reference file, e.g. ".git/HEAD" 
> etc. For some reason the path "//HEAD" is checked and this is causing a 
> delay. Paths starting with "//" are treated in Cygwin as CIFS paths and 
> the delay comes from the timeout when Windows tries to resolve the 
> hostname "HEAD" to a server.

> Subsequent executions of "git status" return immediately as I guess the 
> resolution of "HEAD" as a hostname is cached.

> I don't recall having this problem previously.

> Does anyone else experience this issue?

Is this (or a remote system) an AD member? If names resolution is a culprit,
try setting up cygserver, it may speed up name resolution.


-- 
With best regards,
Andrey Repin
Monday, November 20, 2017 20:01:40

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[Adam Dinwoodie]

On Saturday 18 November 2017 at 09:13 pm +0000, Richard H Lee wrote:
> I have an issue with git where it hangs for 10 to 20 seconds on several
> commands, including "git status". For me this is reproducible on a fresh
> install of Cygwin x64 in Windows 7.
> 
> I get the feeling I am doing something wrong on my end as "git status" is a
> very commonly used command, yet I see no mentions of this on the Cygwin
> mailing list.
> 
> Using gdb I can see git hang in the function validate_headref on an lstat
> call. validate_headref pretty much does what it says and validates the HEAD
> reference file. validate_headref is called multiple times for different
> candidate paths for the HEAD reference file, e.g. ".git/HEAD" etc. For some
> reason the path "//HEAD" is checked and this is causing a delay. Paths
> starting with "//" are treated in Cygwin as CIFS paths and the delay comes
> from the timeout when Windows tries to resolve the hostname "HEAD" to a
> server.
> 
> Subsequent executions of "git status" return immediately as I guess the
> resolution of "HEAD" as a hostname is cached.
> 
> I don't recall having this problem previously.
> 
> Does anyone else experience this issue?

I've seen a couple of reports of this behaviour, although I can't
immediately rememeber whether they were from Git users on this mailing
list or from Cygwin users on the upstream Git mailing list.

Your analysis is spot-on: Git is trying to find the directory that
contains all the metadata for the current working copy, and traversing
up the directory structure to do so.  In circumstances I haven't managed
to characterise (I don't see this problem) it sometimes tries to parse
//HEAD -- on most POSIX systems, this is equivalent to /HEAD, but on
Cygwin it refers to the UNC path \\HEAD, which Windows attempts to look
up on the network.  That network lookup is the cause of the delay you're
seeing.

(I believe this is a bug in Git, on the grounds that (a) Git in general
supports POSIX systems and giving special meaning to paths starting with
`\\` is allowed, if unusual, POSIX behaviour, and (b) Git specifically
supports Cygwin, and this is very well documented Cygwin behaviour.)

In the name of being able to report this usefully upstream (and ideally
being able to reproduce it myself) can you give me a bit more
information about your environment?  Specifically, I'm after:

- The cygcheck output per the bolded bullet in the problem reporting
  guidelines: http://cygwin.com/problems.html.

- The version of Git you're running, per `git --version`, if it hasn't
  been installed using Cygwin's setup-*.exe installers.

- The current working directory when you run `git status`.

- Details of the directory structure of the repository you're running
  `git status` in.  I'm mainly after where the `.git` directory is in
  relation to the current working directory, but if there's anything
  else that's not entirely standard I'd like to know that, too (e.g. it
  being a bare repository).

- Whether you're running Bash in MinTTY, Windows cmd shell, or something
  else.

- If there's anything special about your shell prompt (e.g. you're using
  one of the git prompt tools to include repository status summaries in
  your shell prompt).

Cheers,

Adam

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[Dawid Ferenczy]

Original   message  "Re: Git status delay"  from  "Adam Dinwoodie  
(adam@dinwoodie.org)" sent 21. listopadu 2017, 11:27:28,
msgid:20171121102728.GM20681@dinwoodie.org (3557 bytes):


> Your analysis is spot-on: Git is trying to find the directory that
> contains all the metadata for the current working copy, and traversing
> up the directory structure to do so.  In circumstances I haven't managed
> to characterise (I don't see this problem) it sometimes tries to parse
> //HEAD -- on most POSIX systems, this is equivalent to /HEAD, but on
> Cygwin it refers to the UNC path \\HEAD, which Windows attempts to look
> up on the network.  That network lookup is the cause of the delay you're
> seeing.

> (I believe this is a bug in Git, on the grounds that (a) Git in general
> supports POSIX systems and giving special meaning to paths starting with
> `\\` is allowed, if unusual, POSIX behaviour, and (b) Git specifically
> supports Cygwin, and this is very well documented Cygwin behaviour.)


Hi,

   exactly!  I  can  confirm it. This is a screenshot from SysInternals' Process
   Monitor: https://ferenczy.cz/temp/cygwin-git-hang.png
   
   You  can  see  that  it  hanged  for about 30 seconds trying to open the file
   "\\HEAD\PIPE\wkssvc" which obviously failed with the BAD NETWORK PATH error. 
   On  my  system, it always hangs for the same amount time, it's most likely a 
   timeout.
   
   It  just  suddenly  started to happen (I have a Git status in my prompt so I 
   noticed it when my shell started to behave extremely slowly). I have tried to 
   update both Cygwin and Git and it didn't help.
   
   Also, it's happening even outside of any repository.
   
   I would also say it's more likely a Git's issue than Cygwin's.
 
-- 
S pozdravem,
 Dawid Ferenczy
 Senior web applications developer

 ferenczy@volny.cz
 http://ferenczy.cz
 http://twitter.com/DawidFerenczy

 PGP key ID: 0xA864A330EE1FE92B
___________________________________


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[Dawid Ferenczy]

Original   message  "Re: Git status delay"  from  "Adam Dinwoodie  
(adam@dinwoodie.org)" sent 21. listopadu 2017, 11:27:28,
msgid:20171121102728.GM20681@dinwoodie.org (3557 bytes):


> Your analysis is spot-on: Git is trying to find the directory that
> contains all the metadata for the current working copy, and traversing
> up the directory structure to do so.  In circumstances I haven't managed
> to characterise (I don't see this problem) it sometimes tries to parse
> //HEAD -- on most POSIX systems, this is equivalent to /HEAD, but on
> Cygwin it refers to the UNC path \\HEAD, which Windows attempts to look
> up on the network.  That network lookup is the cause of the delay you're
> seeing.

> (I believe this is a bug in Git, on the grounds that (a) Git in general
> supports POSIX systems and giving special meaning to paths starting with
> `\\` is allowed, if unusual, POSIX behaviour, and (b) Git specifically
> supports Cygwin, and this is very well documented Cygwin behaviour.)


Hi,

   exactly!  I  can  confirm it. This is a screenshot from SysInternals' Process
   Monitor: https://ferenczy.cz/temp/cygwin-git-hang.png
   
   You  can  see  that  it  hanged  for about 30 seconds trying to open the file
   "\\HEAD\PIPE\wkssvc" which obviously failed with the BAD NETWORK PATH error. 
   On  my  system, it always hangs for the same amount time, it's most likely a 
   timeout.
   
   It  just  suddenly  started to happen (I have a Git status in my prompt so I 
   noticed it when my shell started to behave extremely slowly). I have tried to 
   update both Cygwin and Git and it didn't help.
   
   Also, it's happening even outside of any repository.
   
   I would also say it's more likely a Git's issue than Cygwin's.
 
-- 
S pozdravem,
 Dawid Ferenczy
 Senior web applications developer

 ferenczy@volny.cz
 http://ferenczy.cz
 http://twitter.com/DawidFerenczy

 PGP key ID: 0xA864A330EE1FE92B
___________________________________


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[Dawid Ferenczy]

Original   message  "Re: Git status delay"  from  "Adam Dinwoodie  
(adam@dinwoodie.org)" sent 21. listopadu 2017, 11:27:28,
msgid:20171121102728.GM20681@dinwoodie.org (3557 bytes):


> Your analysis is spot-on: Git is trying to find the directory that
> contains all the metadata for the current working copy, and traversing
> up the directory structure to do so.  In circumstances I haven't managed
> to characterise (I don't see this problem) it sometimes tries to parse
> //HEAD -- on most POSIX systems, this is equivalent to /HEAD, but on
> Cygwin it refers to the UNC path \\HEAD, which Windows attempts to look
> up on the network.  That network lookup is the cause of the delay you're
> seeing.

> (I believe this is a bug in Git, on the grounds that (a) Git in general
> supports POSIX systems and giving special meaning to paths starting with
> `\\` is allowed, if unusual, POSIX behaviour, and (b) Git specifically
> supports Cygwin, and this is very well documented Cygwin behaviour.)


Hi,

   exactly!  I  can  confirm it. This is a screenshot from SysInternals' Process
   Monitor: https://ferenczy.cz/temp/cygwin-git-hang.png
   
   You  can  see  that  it  hanged  for about 30 seconds trying to open the file
   "\\HEAD\PIPE\wkssvc" which obviously failed with the BAD NETWORK PATH error. 
   On  my  system, it always hangs for the same amount time, it's most likely a 
   timeout.
   
   It  just  suddenly  started to happen (I have a Git status in my prompt so I 
   noticed it when my shell started to behave extremely slowly). I have tried to 
   update both Cygwin and Git and it didn't help.
   
   Also, it's happening even outside of any repository.
   
   I would also say it's more likely a Git's issue than Cygwin's.
 
-- 
S pozdravem,
 Dawid Ferenczy
 Senior web applications developer

 ferenczy@volny.cz
 http://ferenczy.cz
 http://twitter.com/DawidFerenczy

 PGP key ID: 0xA864A330EE1FE92B
___________________________________


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[Adam Dinwoodie]

On Monday 11 December 2017 at 02:37 pm +0100, Dawid Ferenczy wrote:
>    You  can  see  that  it  hanged  for about 30 seconds trying to open the file
>    "\\HEAD\PIPE\wkssvc" which obviously failed with the BAD NETWORK PATH error. 
>    On  my  system, it always hangs for the same amount time, it's most likely a 
>    timeout.

Hi Dawid,

So I can look into this, I need the information I asked for in the email
you replied to.  To repeat, that's:

> - The cygcheck output per the bolded bullet in the problem reporting
>   guidelines: http://cygwin.com/problems.html.
> 
> - The version of Git you're running, per `git --version`, if it hasn't
>   been installed using Cygwin's setup-*.exe installers.
> 
> - The current working directory when you run `git status`.
> 
> - Details of the directory structure of the repository you're running
>   `git status` in.  I'm mainly after where the `.git` directory is in
>   relation to the current working directory, but if there's anything
>   else that's not entirely standard I'd like to know that, too (e.g. it
>   being a bare repository).
> 
> - Whether you're running Bash in MinTTY, Windows cmd shell, or something
>   else.
> 
> - If there's anything special about your shell prompt (e.g. you're using
>   one of the git prompt tools to include repository status summaries in
>   your shell prompt).

You've included some of that information in your reply, but I do need it
all to be able to look at this.

Also, per the mailing list notes at <https://cygwin.com/lists.html>,
please configure your mailer to not include people's email addresses in
your replies.

Cheers,

Adam

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[Richard H Lee]

On 21/11/2017 10:27, Adam Dinwoodie wrote:
> (I believe this is a bug in Git, on the grounds that (a) Git in general
> supports POSIX systems and giving special meaning to paths starting with
> `\\` is allowed, if unusual, POSIX behaviour, and (b) Git specifically
> supports Cygwin, and this is very well documented Cygwin behaviour.)

I updated Cygwin and this problem has been fixed. Here's the upstream 
commit:
https://github.com/git/git/commit/57dd3dd28724a150e6c6d4c1c8363e1efd49c197.patch

What happened previously was that when is_git_directory("/") was called, 
git blindly appended "/HEAD" to the path, causing "//HEAD" (i.e. a 
network share) to be lstatted. The commit fixes this by only appending 
the '/' before "HEAD" only if it does not end in it already. Hence 
"/HEAD" is now lstatted as it should be.


> In the name of being able to report this usefully upstream (and ideally
> being able to reproduce it myself) can you give me a bit more
> information about your environment?
I think the reason why so few people experienced this issue was that 
certain people have ISPs that use DNS hijacking. This is where 
non-existent DNS names are resolved to a catch-all IP address. They do 
this to monetise domain name typos. E.g. if someone mistypes the DNS 
part of the URL, the ISP's "not found" page will display adverts based 
upon terms extracted from the URL.

So if you lstat("//HEAD") and you are on a network that does DNS 
hijacking, Cygwin will attempt to connect to the ISP's server via SMB. 
As the ISP's server is a publicly facing IP address, it probably just 
black holes any incoming connection requests. So instead of receiving an 
immediate connection refusal, the TCP connection request just times out. 
This timeout was the cause of the delay.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Git status delay

[cyg Simple]

On 12/11/2017 5:04 PM, Richard H Lee wrote:
> 
> So if you lstat("//HEAD") and you are on a network that does DNS
> hijacking, Cygwin will attempt to connect to the ISP's server via SMB.
> As the ISP's server is a publicly facing IP address, it probably just
> black holes any incoming connection requests. So instead of receiving an
> immediate connection refusal, the TCP connection request just times out.
> This timeout was the cause of the delay.
> 

I'm of the belief that instead of DNS hijacking as you suppose this is
related to the Windows OS timeout values for servers referenced by
\\SERVER which in this case is \\HEAD.  The timeout values can be
adjusted but 30 seconds is the default value which is noticeable.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple