DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:subject:to:references:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=Ap6ey51xZ/V8VjqS
	mt0Ab164psDpB0pZksaTZaMo6mHYAS8a0mLWn0fy5XnRp6eTNFFUq4CSINb3MXt4
	0/5IYye59obcSyWeU2umX61gEDV5Y06dCP/aKi0u1kxkXTT/e96aUa69bgk/La5k
	hyu/PVQazd4C3h8yIC8gIfmKcKM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: Richard H Lee <ricardohenrylee AT gmail DOT com>
Subject: Re: Git status delay
To: cygwin AT cygwin DOT com
References: <092c4159-1f86-a64a-6ae1-c9909ef4ef90 AT gmail DOT com> <20171121102728 DOT GM20681 AT dinwoodie DOT org> <1867005492 DOT 20171126014157 AT volny DOT cz>
Message-ID: <e0911723-2b71-cfda-09b1-1eb54950f928@gmail.com>
Date: Mon, 11 Dec 2017 22:04:16 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <1867005492.20171126014157@volny.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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