{"thread":{"id":"65691","subject":"Re: Expected test suite behavior","startedAt":"2026-05-25T06:21:06Z","lastAt":"2026-05-26T01:12:02Z","messageCount":7,"participants":["Michael Montalbo","Jeff King","Amogh Dambal","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"544032","messageId":"CAC2QwmKgQW2c6_OhepsB1hzXYHxpX0X4eyQS0dPcxRZLOnCdig@mail.gmail.com","threadId":"65691","inReplyTo":null,"subject":"Re: Expected test suite behavior","fromName":"Michael Montalbo","fromEmail":"mmontalbo@gmail.com","sentAt":"2026-05-25T06:20:54Z","receivedAt":"2026-05-25T06:21:06Z","isPatch":false,"body":"Amogh Dambal <amoghdambal1@gmail.com> writes:\n> Hey folks,\n>\n> I wanted to get started hacking on/poking around the Git source, but I'm\n> seeing some behavior with the tests that I can't quite figure out.\n> [...]\n> Is there a README/documentation I've missed reading that can help\n> explain the behavior I'm seeing?\n>\n\nHello. If you run `make test GIT_TEST_OPTS=--verbose` or uncomment\nL16 of t/Makefile is there more information describing the issue?\n"},{"id":"544040","messageId":"20260525072711.GE2737798@coredump.intra.peff.net","threadId":"65691","inReplyTo":"CAC2QwmKgQW2c6_OhepsB1hzXYHxpX0X4eyQS0dPcxRZLOnCdig@mail.gmail.com","subject":"Re: Expected test suite behavior","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-05-25T07:27:11Z","receivedAt":"2026-05-25T07:27:12Z","isPatch":false,"body":"On Sun, May 24, 2026 at 11:20:54PM -0700, Michael Montalbo wrote:\n\n> Amogh Dambal <amoghdambal1@gmail.com> writes:\n> > Hey folks,\n> >\n> > I wanted to get started hacking on/poking around the Git source, but I'm\n> > seeing some behavior with the tests that I can't quite figure out.\n> > [...]\n> > Is there a README/documentation I've missed reading that can help\n> > explain the behavior I'm seeing?\n> \n> Hello. If you run `make test GIT_TEST_OPTS=--verbose` or uncomment\n> L16 of t/Makefile is there more information describing the issue?\n\nYou can't use --verbose when running under the \"prove\" TAP harness\n(which the OP seems to be doing). You can use --verbose-log instead, and\nthen output is in t/test-results/t1234-whatever.out.\n\nHowever, when debugging tests I find it easier to focus on a single\nfailing test by running it individually, like:\n\n  cd t\n  ./t1234-whatever.sh -v -i -x\n\nThat will stop at the first failure (-i), showing the output of all\ncommands (-v), and additionally enabling shell tracing (-x) so you can\nsee which command in the test failed.\n\n-Peff\n"},{"id":"544078","messageId":"23221493-ea81-47c3-9647-6c6ac8d03360@gmail.com","threadId":"65691","inReplyTo":"20260525072711.GE2737798@coredump.intra.peff.net","subject":"Re: Expected test suite behavior","fromName":"Amogh Dambal","fromEmail":"amoghdambal1@gmail.com","sentAt":"2026-05-25T22:01:23Z","receivedAt":"2026-05-25T22:01:26Z","isPatch":false,"body":"Thanks for the replies, and the pointers!\n\n\n >> Hello. If you run `make test GIT_TEST_OPTS=--verbose` or uncomment\n >> L16 of t/Makefile is there more information describing the issue?\n\n > You can use --verbose-log instead, and\n > then output is in t/test-results/t1234-whatever.out.\n\n\n`GIT_TEST_OPTS=--verbose` was very illuminating. I captured \nSTDOUT/STDERR: `make test GIT_TEST_OPTS=--verbose &> \ngit-test-verbose-fail.tmp`, which shows that almost every test fails \n`check_config` because a `git init` is creating a `.git/config` file \nwhose executable bit is set:\n\n--\nInitialized empty Git repository in /root/git/t/trash \ndirectory.t0001-init/plain/.git/\nplain/.git/config is executable?\nnot ok 1 - plain\n\n[...]\n\n\nHowever, I'm not able to reproduce this, e.g. directly using the local \nbuilt binary seems to work fine:\n\nmkdir -p /tmp/debug && cd /tmp/debug\n/root/git/git init plain\nls -alhrt /tmp/debug/plain/.git\nroot@ec94ab1b260e:/tmp/debug# ls -alhrt /tmp/debug/plain/.git\ntotal 24K\n-rw-r--r-- 1 root root   92 May 25 21:26 config\ndrwxr-xr-x 3 root root 4.0K May 25 21:26 ..\ndrwxr-xr-x 4 root root 4.0K May 25 21:26 refs\ndrwxr-xr-x 4 root root 4.0K May 25 21:26 objects\n-rw-r--r-- 1 root root   23 May 25 21:26 HEAD\ndrwxr-xr-x 4 root root 4.0K May 25 21:26 .\n\nIn fact, even the specific test directory that I assume is being checked \nreports properly set bits on the `config` file:\n\nroot@f695346357b9:~/git# ls -alhrt t/trash\\ directory.t0001-init/plain/.git/\ntotal 12K\ndrwxr-xr-x  3 root root  96 May 25 21:08 ..\ndrwxr-xr-x  3 root root  96 May 25 21:08 info\n-rwxr-xr-x  1 root root  73 May 25 21:08 description\ndrwxr-xr-x 16 root root 512 May 25 21:08 hooks\n-rw-r--r--  1 root root 111 May 25 21:08 config\ndrwxr-xr-x  4 root root 128 May 25 21:08 refs\n-rw-r--r--  1 root root  23 May 25 21:08 HEAD\ndrwxr-xr-x  9 root root 288 May 25 21:08 .\ndrwxr-xr-x  4 root root 128 May 25 21:08 objects\n\nI've further checked that the POSIXPERM requirement is being set and \nverified that there are no shell differences (I'm using /bin/bash as my \nmain shell in the Docker container, while the test scripts use /bin/sh \n(which on this Docker container is symlinked to `dash`):\n\nroot@ec94ab1b260e:~/git/t# ls -alhrt /bin/sh\nlrwxrwxrwx 1 root root 4 Feb  4  2025 /bin/sh -> dash\n\nI'm sure that I'm missing something blindingly obvious with respect to \nmy setup, but I have not yet been able to figure out what that might be.\n"},{"id":"544079","messageId":"ahTKq_zCmEDJpoN5@fruit.crustytoothpaste.net","threadId":"65691","inReplyTo":"23221493-ea81-47c3-9647-6c6ac8d03360@gmail.com","subject":"Re: Expected test suite behavior","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-05-25T22:18:19Z","receivedAt":"2026-05-25T22:18:22Z","isPatch":false,"body":"On 2026-05-25 at 22:01:23, Amogh Dambal wrote:\n> `GIT_TEST_OPTS=--verbose` was very illuminating. I captured STDOUT/STDERR:\n> `make test GIT_TEST_OPTS=--verbose &> git-test-verbose-fail.tmp`, which\n> shows that almost every test fails `check_config` because a `git init` is\n> creating a `.git/config` file whose executable bit is set:\n\nWhat are the OS and file system on the host?  We tend to see\nexecutable bits set when NTFS, FAT, or other Windows-adjacent file\nsystems are used on Linux and you're mounting `$(PWD)` into the\ncontainer as a volume.\n\n> --\n> Initialized empty Git repository in /root/git/t/trash\n> directory.t0001-init/plain/.git/\n> plain/.git/config is executable?\n> not ok 1 - plain\n> \n> [...]\n> \n> \n> However, I'm not able to reproduce this, e.g. directly using the local built\n> binary seems to work fine:\n> \n> mkdir -p /tmp/debug && cd /tmp/debug\n> /root/git/git init plain\n> ls -alhrt /tmp/debug/plain/.git\n> root@ec94ab1b260e:/tmp/debug# ls -alhrt /tmp/debug/plain/.git\n> total 24K\n> -rw-r--r-- 1 root root   92 May 25 21:26 config\n> drwxr-xr-x 3 root root 4.0K May 25 21:26 ..\n> drwxr-xr-x 4 root root 4.0K May 25 21:26 refs\n> drwxr-xr-x 4 root root 4.0K May 25 21:26 objects\n> -rw-r--r-- 1 root root   23 May 25 21:26 HEAD\n> drwxr-xr-x 4 root root 4.0K May 25 21:26 .\n\nGit doesn't use `/tmp` for most files in the tests.  Those are stored\nunder `t/`, so you'd want to create your test directory there.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"544080","messageId":"4649049a-ded5-4cc6-bc2b-d5f543e6df99@gmail.com","threadId":"65691","inReplyTo":"ahTKq_zCmEDJpoN5@fruit.crustytoothpaste.net","subject":"Re: Expected test suite behavior","fromName":"Amogh Dambal","fromEmail":"amoghdambal1@gmail.com","sentAt":"2026-05-25T22:25:11Z","receivedAt":"2026-05-25T22:25:13Z","isPatch":false,"body":" > What are the OS and file system on the host?  We tend to see\n > executable bits set when NTFS, FAT, or other Windows-adjacent file\n > systems are used on Linux and you're mounting `$(PWD)` into the\n > container as a volume.\n\nAh, this is a smoking gun. I'm not on a Windows-adjacent file system; \nI'm running macOS Sequoia 15.5 on the host. Specifically:\n\n$ uname -msprsv\nDarwin 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:26 PDT \n2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T8112 arm64 arm\n\nBut I am mounting $(PWD) into the container as a volume.\n\n\n > Git doesn't use `/tmp` for most files in the tests.  Those are stored\n > under `t/`, so you'd want to create your test directory there.\n\nACK, good to know, thanks! I am still seeing the same behavior with a \n`debug` directory under `t/`:\n\nroot@ec94ab1b260e:~/git/t/debug# /root/git/git init plain\nroot@ec94ab1b260e:~/git/t/debug# ls -alhrt \n/root/git/t/debug/plain/.git/config\n-rw-r--r-- 1 root root 111 May 25 22:24 /root/git/t/debug/plain/.git/config\n"},{"id":"544086","messageId":"ahTsTDhVPkHTEbB_@fruit.crustytoothpaste.net","threadId":"65691","inReplyTo":"4649049a-ded5-4cc6-bc2b-d5f543e6df99@gmail.com","subject":"Re: Expected test suite behavior","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-05-26T00:41:48Z","receivedAt":"2026-05-26T00:41:50Z","isPatch":false,"body":"On 2026-05-25 at 22:25:11, Amogh Dambal wrote:\n> > What are the OS and file system on the host?  We tend to see\n> > executable bits set when NTFS, FAT, or other Windows-adjacent file\n> > systems are used on Linux and you're mounting `$(PWD)` into the\n> > container as a volume.\n> \n> Ah, this is a smoking gun. I'm not on a Windows-adjacent file system; I'm\n> running macOS Sequoia 15.5 on the host. Specifically:\n> \n> $ uname -msprsv\n> Darwin 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:26 PDT 2025;\n> root:xnu-11417.121.6~2/RELEASE_ARM64_T8112 arm64 arm\n> \n> But I am mounting $(PWD) into the container as a volume.\n\nI wouldn't expect that to be a problem, then.  macOS uses Unix-style\npermissions and I've never seen odd permissions behaviour mounting a\nmacOS APFS file system into a container.  I will, however, note that I\nam using a case-sensitive APFS volume, but I cannot imagine how this\nwould occur with _any_ macOS APFS volume mounted into a Linux container.\n\n> > Git doesn't use `/tmp` for most files in the tests.  Those are stored\n> > under `t/`, so you'd want to create your test directory there.\n> \n> ACK, good to know, thanks! I am still seeing the same behavior with a\n> `debug` directory under `t/`:\n> \n> root@ec94ab1b260e:~/git/t/debug# /root/git/git init plain\n> root@ec94ab1b260e:~/git/t/debug# ls -alhrt\n> /root/git/t/debug/plain/.git/config\n> -rw-r--r-- 1 root root 111 May 25 22:24 /root/git/t/debug/plain/.git/config\n\nI think I know what the problem is: you're running as root.  I suspect\n`test -x` in the test says that you have permission to execute it\nbecause you're root and root always ignores permissions.  My guess is\nthat most of the tests you're failing have to do with permissions of\nsome sort that are being ignored because you're privileged.\n\nIn general, you would not want to run this as root.  Use `adduser` to\ncreate yourself a regular user and then use the `USER` directive in the\nDockerfile to change users.  I don't run the tests as root and I'm sure\nnone of the other regular contributors do, either.  Running unprivileged\nin a container is a best practice anyway.\n\nI'll just note that if you just want to do Git development, macOS is a\nfully supported platform on which to do that.  I will admit most of the\nmajor contributors (with the notable exception of the Git for Windows\nmaintainer) do use Linux and of course I like and endorse Debian, but\nmacOS should build and run just fine if you prefer that.\n\nBut if you do want to use a container, I'd try unprivileged and see if\nsubstantially more of the tests pass.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"544087","messageId":"xmqqa4tnnfds.fsf@gitster.g","threadId":"65691","inReplyTo":"ahTsTDhVPkHTEbB_@fruit.crustytoothpaste.net","subject":"Re: Expected test suite behavior","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-05-26T01:11:59Z","receivedAt":"2026-05-26T01:12:02Z","isPatch":false,"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I think I know what the problem is: you're running as root.  I suspect\n> `test -x` in the test says that you have permission to execute it\n> because you're root and root always ignores permissions.  My guess is\n> that most of the tests you're failing have to do with permissions of\n> some sort that are being ignored because you're privileged.\n\nI know !SANITY defeats a-rw and lets the tester read or write to the\npath, but this is the first time I heard that !SANITY defeats a-x\nand lets the tester _execute_ it.\n\nI do not think we drop POSIXPERM prereq when !SANITY automatically,\nand I do not think we should, but we should probably have an\nautomated check to drop POSIXPERM?\n\n    (\n\t# is an unexecutable look to the user as executable?\n\tumask 0; >testfile; chmod a-w testfile; test -x testfile;\n\tstatus=$?;\n\trm -f testfile; exit $status\n    )\n\n> I'll just note that if you just want to do Git development, macOS is a\n> fully supported platform on which to do that.  I will admit most of the\n> major contributors (with the notable exception of the Git for Windows\n> maintainer) do use Linux and of course I like and endorse Debian, but\n> macOS should build and run just fine if you prefer that.\n\nHear hear.\n\nWe want to encourage developers to do more _native_ development on\ntheir own system, and this is not limited to macOS.  As long as\nusers on a particular platform rely on working Git there, we are\nbetter off if we have more people actively using that platform to\nbuild, test, develop on, and debug Git for their own use.\n\nThanks.\n\n"}]}