[x] I was not able to find an open or closed issue matching what I'm seeing
This is conceptually related to #1301, but not configuration-dependent.
Setup
Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
64-bit.
$ git --version --build-options
git version 2.45.2.windows.1
cpu: x86_64
built from commit: 91d03cb2e4fbf6ad961ace739b8a646868cb154d
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
I have confirmed this issue on multiple machines running different versions and architectures of Windows. The technical details given here are for a Windows 11 ARM64 system running the 64-bit x86-64 build of Git for Windows (the system automatically takes care of the necessary emulation). But this issue is not specific in any way to ARM64 systems, and this is with an official stable x86-64 build, not an ARM64 build. The output of ver shows the major version number as "10" but this is a Windows 11 system.
$ cmd.exe /c ver
Microsoft Windows [Version 10.0.22631.3880
The reason I have given the details of that installation, rather than my x86-64 Windows 10 installation, is that Git for Windows is installed via scoop in that other installation. I am unsure if reports from such an installation are considered as useful, since the template seems to indicate that a install-options.txt file whose contents can be shown by one of the exact commands in the template is required. I would be pleased to provide more information or set up additional environments if needed.
What options did you set as part of the installation? Or did you choose the
defaults?
In the installation whose details are shown, I used the x86-64 installer, running as a limited user, to install in the limited user's local Programs directory, without adding git to the PATH environment variable. But I have confirmed that this issue does not depend on running as a limited user, installing in that way, or refraining from modifying the PATH.
Any other interesting things about your environment that might be related
to the issue you're seeing?
As far as I can tell, this happens with Git for Windows in all environments. It does not happen when running Git on operating systems other than Windows.
Details
Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
Technical details presented here are from running Git from Bash in the provided Git Bash shell, but I have confirmed that this is not specific to that.
git init gitignore-dir
cd gitignore-dir
mkdir .gitignore
touch .gitignore/a
git add .
git status
What did you expect to occur after running these commands?
I expect no errors or warnings to be reported, even though having a directory named .gitignore is unusual and should probably be avoided. The reason I expect this is that it works outside of Windows.
Secondarily, if all operations have completed successfully with their full intended resulting state, then I expect that no messages are issued that would tend to cause an experienced user of Git for Windows to believe that some operation failed or was only partially successful.
What actually happened instead?
Although staging succeeds, the git add . and git status commands output:
warning: unable to access '.gitignore': Permission denied
But both commands actually succeeded fully, including at staging .gitignore/a and showing .gitignore/a as staged:
$ git init gitignore-dir
Initialized empty Git repository in C:/Users/pickens/gitignore-dir/.git/
$ cd gitignore-dir
$ mkdir .gitignore
$ touch .gitignore/a
$ git add .
warning: unable to access '.gitignore': Permission denied
$ git status
warning: unable to access '.gitignore': Permission denied
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: .gitignore/a
I do not insist that this warning is technically wrong. My guess is that an attempt is made to open it as a regular file, which fails because it is a directory and reports that failure accurately, and then there is no undesirable effect from this besides the warning, since a directory named .gitignore is not treated specially. But this appears to be indicating that not all files were staged or that the resulting state differs from what the user may have intended, which is not the case. Furthermore, on non-Windows systems, these commands have the same successful effect, while not indicating any errors or warnings.
If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?
This is conceptually related to #1301, but not configuration-dependent.
Setup
64-bit.
I have confirmed this issue on multiple machines running different versions and architectures of Windows. The technical details given here are for a Windows 11 ARM64 system running the 64-bit x86-64 build of Git for Windows (the system automatically takes care of the necessary emulation). But this issue is not specific in any way to ARM64 systems, and this is with an official stable x86-64 build, not an ARM64 build. The output of
vershows the major version number as "10" but this is a Windows 11 system.The reason I have given the details of that installation, rather than my x86-64 Windows 10 installation, is that Git for Windows is installed via
scoopin that other installation. I am unsure if reports from such an installation are considered as useful, since the template seems to indicate that ainstall-options.txtfile whose contents can be shown by one of the exact commands in the template is required. I would be pleased to provide more information or set up additional environments if needed.In the installation whose details are shown, I used the x86-64 installer, running as a limited user, to install in the limited user's local
Programsdirectory, without addinggitto thePATHenvironment variable. But I have confirmed that this issue does not depend on running as a limited user, installing in that way, or refraining from modifying thePATH.As far as I can tell, this happens with Git for Windows in all environments. It does not happen when running Git on operating systems other than Windows.
Details
Technical details presented here are from running Git from Bash in the provided Git Bash shell, but I have confirmed that this is not specific to that.
I expect no errors or warnings to be reported, even though having a directory named
.gitignoreis unusual and should probably be avoided. The reason I expect this is that it works outside of Windows.Secondarily, if all operations have completed successfully with their full intended resulting state, then I expect that no messages are issued that would tend to cause an experienced user of Git for Windows to believe that some operation failed or was only partially successful.
Although staging succeeds, the
git add .andgit statuscommands output:But both commands actually succeeded fully, including at staging
.gitignore/aand showing.gitignore/aas staged:I do not insist that this warning is technically wrong. My guess is that an attempt is made to open it as a regular file, which fails because it is a directory and reports that failure accurately, and then there is no undesirable effect from this besides the warning, since a directory named
.gitignoreis not treated specially. But this appears to be indicating that not all files were staged or that the resulting state differs from what the user may have intended, which is not the case. Furthermore, on non-Windows systems, these commands have the same successful effect, while not indicating any errors or warnings.This happens whenever a directory named
.gitignoreis present, and is not specific to a particular repository. I expect that this condition is typically accidental. I was motivated to check how Git for Windows behaved in this situation by https://github.com/gitbutlerapp/gitbutler/issues/3876 and https://github.com/Byron/gitoxide/pull/1386.