This is the mail archive of the
mailing list for the Cygwin project.
Re: Git status delay
- From: Adam Dinwoodie <adam at dinwoodie dot org>
- To: cygwin at cygwin dot com
- Date: Tue, 21 Nov 2017 10:27:28 +0000
- Subject: Re: Git status delay
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
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
> 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
(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
- 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
- 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).
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple