Amogh Dambal <amoghdambal1@gmail.com> writes:

Hello. If you run `make test GIT_TEST_OPTS=--verbose` or uncomment L16 of t/Makefile is there more information describing the issue?

On Sun, May 24, 2026 at 11:20:54PM -0700, Michael Montalbo wrote:

You can't use --verbose when running under the "prove" TAP harness (which the OP seems to be doing). You can use --verbose-log instead, and then output is in t/test-results/t1234-whatever.out.

However, when debugging tests I find it easier to focus on a single failing test by running it individually, like:

  cd t
  ./t1234-whatever.sh -v -i -x

That will stop at the first failure (-i), showing the output of all commands (-v), and additionally enabling shell tracing (-x) so you can see which command in the test failed.

-Peff

Thanks for the replies, and the pointers!

 >> Hello. If you run `make test GIT_TEST_OPTS=--verbose` or uncomment
 >> L16 of t/Makefile is there more information describing the issue?

 > You can use --verbose-log instead, and
 > then output is in t/test-results/t1234-whatever.out.

`GIT_TEST_OPTS=--verbose` was very illuminating. I captured STDOUT/STDERR: `make test GIT_TEST_OPTS=--verbose &> git-test-verbose-fail.tmp`, which shows that almost every test fails `check_config` because a `git init` is creating a `.git/config` file whose executable bit is set:

-- Initialized empty Git repository in /root/git/t/trash directory.t0001-init/plain/.git/ plain/.git/config is executable? not ok 1 - plain

[...]

However, I'm not able to reproduce this, e.g. directly using the local built binary seems to work fine:

mkdir -p /tmp/debug && cd /tmp/debug /root/git/git init plain ls -alhrt /tmp/debug/plain/.git root@ec94ab1b260e:/tmp/debug# ls -alhrt /tmp/debug/plain/.git total 24K -rw-r--r-- 1 root root 92 May 25 21:26 config drwxr-xr-x 3 root root 4.0K May 25 21:26 .. drwxr-xr-x 4 root root 4.0K May 25 21:26 refs drwxr-xr-x 4 root root 4.0K May 25 21:26 objects -rw-r--r-- 1 root root 23 May 25 21:26 HEAD drwxr-xr-x 4 root root 4.0K May 25 21:26 .

In fact, even the specific test directory that I assume is being checked reports properly set bits on the `config` file:

root@f695346357b9:~/git# ls -alhrt t/trash\ directory.t0001-init/plain/.git/ total 12K drwxr-xr-x 3 root root 96 May 25 21:08 .. drwxr-xr-x 3 root root 96 May 25 21:08 info -rwxr-xr-x 1 root root 73 May 25 21:08 description drwxr-xr-x 16 root root 512 May 25 21:08 hooks -rw-r--r-- 1 root root 111 May 25 21:08 config drwxr-xr-x 4 root root 128 May 25 21:08 refs -rw-r--r-- 1 root root 23 May 25 21:08 HEAD drwxr-xr-x 9 root root 288 May 25 21:08 . drwxr-xr-x 4 root root 128 May 25 21:08 objects

I've further checked that the POSIXPERM requirement is being set and verified that there are no shell differences (I'm using /bin/bash as my main shell in the Docker container, while the test scripts use /bin/sh (which on this Docker container is symlinked to `dash`):

root@ec94ab1b260e:~/git/t# ls -alhrt /bin/sh lrwxrwxrwx 1 root root 4 Feb 4 2025 /bin/sh -> dash

I'm sure that I'm missing something blindingly obvious with respect to my setup, but I have not yet been able to figure out what that might be.

On 2026-05-25 at 22:01:23, Amogh Dambal wrote:

What are the OS and file system on the host? We tend to see executable bits set when NTFS, FAT, or other Windows-adjacent file systems are used on Linux and you're mounting `$(PWD)` into the container as a volume.

Git doesn't use `/tmp` for most files in the tests. Those are stored under `t/`, so you'd want to create your test directory there.

 > What are the OS and file system on the host?  We tend to see
 > executable bits set when NTFS, FAT, or other Windows-adjacent file
 > systems are used on Linux and you're mounting `$(PWD)` into the
 > container as a volume.

Ah, this is a smoking gun. I'm not on a Windows-adjacent file system; I'm running macOS Sequoia 15.5 on the host. Specifically:

$ uname -msprsv Darwin 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:26 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T8112 arm64 arm

But I am mounting $(PWD) into the container as a volume.

 > Git doesn't use `/tmp` for most files in the tests.  Those are stored
 > under `t/`, so you'd want to create your test directory there.

ACK, good to know, thanks! I am still seeing the same behavior with a `debug` directory under `t/`:

root@ec94ab1b260e:~/git/t/debug# /root/git/git init plain root@ec94ab1b260e:~/git/t/debug# ls -alhrt /root/git/t/debug/plain/.git/config -rw-r--r-- 1 root root 111 May 25 22:24 /root/git/t/debug/plain/.git/config

On 2026-05-25 at 22:25:11, Amogh Dambal wrote:

I wouldn't expect that to be a problem, then. macOS uses Unix-style permissions and I've never seen odd permissions behaviour mounting a macOS APFS file system into a container. I will, however, note that I am using a case-sensitive APFS volume, but I cannot imagine how this would occur with _any_ macOS APFS volume mounted into a Linux container.

I think I know what the problem is: you're running as root. I suspect `test -x` in the test says that you have permission to execute it because you're root and root always ignores permissions. My guess is that most of the tests you're failing have to do with permissions of some sort that are being ignored because you're privileged.

In general, you would not want to run this as root. Use `adduser` to create yourself a regular user and then use the `USER` directive in the Dockerfile to change users. I don't run the tests as root and I'm sure none of the other regular contributors do, either. Running unprivileged in a container is a best practice anyway.

I'll just note that if you just want to do Git development, macOS is a fully supported platform on which to do that. I will admit most of the major contributors (with the notable exception of the Git for Windows maintainer) do use Linux and of course I like and endorse Debian, but macOS should build and run just fine if you prefer that.

But if you do want to use a container, I'd try unprivileged and see if substantially more of the tests pass.

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

I know !SANITY defeats a-rw and lets the tester read or write to the path, but this is the first time I heard that !SANITY defeats a-x and lets the tester _execute_ it.

I do not think we drop POSIXPERM prereq when !SANITY automatically, and I do not think we should, but we should probably have an automated check to drop POSIXPERM?

    (
	# is an unexecutable look to the user as executable?
	umask 0; >testfile; chmod a-w testfile; test -x testfile;
	status=$?;
	rm -f testfile; exit $status
    )

Hear hear.

We want to encourage developers to do more _native_ development on their own system, and this is not limited to macOS. As long as users on a particular platform rely on working Git there, we are better off if we have more people actively using that platform to build, test, develop on, and debug Git for their own use.

Thanks.