Description
On the git-for-windows google groups Michael F reported, and resolved, an issue as detailed below.
I've copied it here for a broader audience to share the benefits and for assisting folks in debugging local issues.
Not sure if this is best group, but here it goes.
I have two servers running Windows Server standard edition 2008 R2 (both ver commands return version 6.1.7601). They are not perfectly identical, but close (one has IIS and SQL Server running).
I downloaded and installed latest git-for-windows 64-bit edition on both for the first time to be begin the transition from our old software-control-system to 'git'. So created a simple, 'junk' repository for testing.
Both installations were right out-of-box, taking all default recommendations, and both return the same information from 'git --version' (version 2.20.1.windows.1) as you would expect.
On one machine, everything is working fine as expected. I could initialize a test repo, add a file, commit, etc.
On the second machine, 'git add ' returns "Fatal: cannot use .git/info/exclude as an exclude file". I've compared the file '.git/info/exclude' on both machines and they are the default file that has a comment explaining exclude files.
Similarly, 'git status' returns the same error, basically, just about any git command beyond 'git init' and 'git --version' returns this error.
Any thoughts or ideas to look for? I've compared file permissions in the two machine's where I'm working and I have full control.
Thanks,
Michael F
Jan 16
So, some additional info as I try to figure this out.
The problem exists even on a brand new repo. I move to an empty directory, run 'git init' and it seems to work, but then run 'git status' and have the same error.
I checked and from the same bash shell window, 'cat .git/info/exclude' reads and displays the default file as created by 'git init' with no problems, so file permissions and directory permissions seem okay.
Thinking it might be some other executable being found along the path, I re-configured the system/user path to be very 'bare bones', with just windows\ windows\system32 and the default entries for windows powershell.
I then found that I could turn on several trace environment variables and tried those. Unfortunately, they didn't give me much:
'GIT_TRACE=true git status' shows the last trace statement at git.c:418, just reporting 'trace: built-in: git status'.
'GIT_TRACE_SETUP=true git status' shows the last statement at chdir-notify.c:67 'setup chdir from xxx to xxx' (the same directory before and after)
At this point, I'm toying with trying to learn how to build git-for-windows on one of the platforms that fails so I can maybe step through some of the code. It seems to be failing in the call to add_excludes(). But having never worked in this code, I'm a bit lost so any advice would be appreciated.
Michael F
Jan 17
Narrowed it down quite a bit. I built 'git' using the sdk and found the failure was in dir.c:851. The call to lstat() was failing and temporarily changing to stat() confirmed this. (I discovered that lstat() was returning -1 and setting errno == 40, which is EL3RST ?!?!?? ).
I was trying to work with repositories that were on my T:\ drive. This is actually a network drive that is mounted back onto 'c:\mywork\tdrive'. So apparently some of the file system calls were failing. When I move to 'c:\mywork\tdrive\gittesting' directly instead of 't:\gittesting', everything works correctly.
If I map this drive on another machine, it still gives me errors. Is there an issue with working on network drives?
Michael F
Jan 18
Well I've 'solved' the mystery. I had a local folder on my C: drive shared out to several other workstations, all mapping the shared drive as P:. And so all the scripts and things would work the same, I had also 'mapped' the local folder on the local machine also as 'P:'. And 'lstat()' and other file-system calls doesn't seem to like that.
So on the local machine, I disconnected the 'mapped network drive', and then used the 'subst P: C:\pdrivefolder' command. The file system must treat this slightly differently. Although to the file explorer and any other tools, it still works as any other drive. Now running git in any folder on my 'P:' drive works flawlessly.
So, sorry to have troubled everyone with all my raving, but the problem seems to be when 'mapping' a network drive letter back onto the local machine. Use 'subst' instead. Or, I also found that you can make a registry entry to keep the substitution across reboots.
Not sure if this is best group, but here it goes.
I have two servers running Windows Server standard edition 2008 R2 (both ver commands return version 6.1.7601). They are not perfectly identical, but close (one has IIS and SQL Server running).
I downloaded and installed latest git-for-windows 64-bit edition on both for the first time to be begin the transition from our old software-control-system to 'git'. So created a simple, 'junk' repository for testing.
Both installations were right out-of-box, taking all default recommendations, and both return the same information from 'git --version' (version 2.20.1.windows.1) as you would expect.
On one machine, everything is working fine as expected. I could initialize a test repo, add a file, commit, etc.
On the second machine, 'git add ' returns "Fatal: cannot use .git/info/exclude as an exclude file". I've compared the file '.git/info/exclude' on both machines and they are the default file that has a comment explaining exclude files.
Similarly, 'git status' returns the same error, basically, just about any git command beyond 'git init' and 'git --version' returns this error.
Any thoughts or ideas to look for? I've compared file permissions in the two machine's where I'm working and I have full control.
Thanks,
Michael F
Jan 16
So, some additional info as I try to figure this out.
The problem exists even on a brand new repo. I move to an empty directory, run 'git init' and it seems to work, but then run 'git status' and have the same error.
I checked and from the same bash shell window, 'cat .git/info/exclude' reads and displays the default file as created by 'git init' with no problems, so file permissions and directory permissions seem okay.
Thinking it might be some other executable being found along the path, I re-configured the system/user path to be very 'bare bones', with just windows\ windows\system32 and the default entries for windows powershell.
I then found that I could turn on several trace environment variables and tried those. Unfortunately, they didn't give me much:
'GIT_TRACE=true git status' shows the last trace statement at git.c:418, just reporting 'trace: built-in: git status'.
'GIT_TRACE_SETUP=true git status' shows the last statement at chdir-notify.c:67 'setup chdir from xxx to xxx' (the same directory before and after)
At this point, I'm toying with trying to learn how to build git-for-windows on one of the platforms that fails so I can maybe step through some of the code. It seems to be failing in the call to add_excludes(). But having never worked in this code, I'm a bit lost so any advice would be appreciated.
Michael F
Jan 17
Narrowed it down quite a bit. I built 'git' using the sdk and found the failure was in dir.c:851. The call to lstat() was failing and temporarily changing to stat() confirmed this. (I discovered that lstat() was returning -1 and setting errno == 40, which is EL3RST ?!?!?? ).
I was trying to work with repositories that were on my T:\ drive. This is actually a network drive that is mounted back onto 'c:\mywork\tdrive'. So apparently some of the file system calls were failing. When I move to 'c:\mywork\tdrive\gittesting' directly instead of 't:\gittesting', everything works correctly.
If I map this drive on another machine, it still gives me errors. Is there an issue with working on network drives?
Michael F
Jan 18
Well I've 'solved' the mystery. I had a local folder on my C: drive shared out to several other workstations, all mapping the shared drive as P:. And so all the scripts and things would work the same, I had also 'mapped' the local folder on the local machine also as 'P:'. And 'lstat()' and other file-system calls doesn't seem to like that.
So on the local machine, I disconnected the 'mapped network drive', and then used the 'subst P: C:\pdrivefolder' command. The file system must treat this slightly differently. Although to the file explorer and any other tools, it still works as any other drive. Now running git in any folder on my 'P:' drive works flawlessly.
So, sorry to have troubled everyone with all my raving, but the problem seems to be when 'mapping' a network drive letter back onto the local machine. Use 'subst' instead. Or, I also found that you can make a registry entry to keep the substitution across reboots.
(Template trimmed)