Misleading warning when a directory is named .gitignore

[EliahKagan]

• 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.

$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Default Branch Option: main
Path Option: BashOnly
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: FFOnly
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• 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.

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

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 happens whenever a directory named .gitignore is 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 gitbutlerapp/gitbutler#3876 and GitoxideLabs/gitoxide#1386.

[dscho]

Thank you @rimrul for fixing this!

[EliahKagan]

Thanks!

[dscho]

Thanks!

Please test the latest snapshot.

[EliahKagan]

I have just tested PortableGit-prerelease-2.48.0-rc2.windows.1-472-g0c796d3013-20250123145154-64-bit.7z.exe, downloded from the snapshot page. As expected, the bug is fixed. Neither warning: unable to access '.gitignore': Permission denied nor any other error message is printed when git add . or git status are run.

For comparison since this was on a different Windows 11 system, and since I had not used PortableGit before to test this, I also tested PortableGit-2.47.1.2-64-bit.7z.exe on the same system and confirmed that the bug is observable with that. Thus, that I did not observe it with the snapshot is a pretty strong indication that the bug really is fixed in the snapshot.