From: Junio C Hamano Date: Sun, 30 Nov 2025 06:09:22 GMT Subject: Re: [PATCH 05/10] t0301: another fix for Windows compatibility Message-ID: In-Reply-To: "Johannes Schindelin via GitGitGadget" writes: > From: Johannes Schindelin > > Just like 0fdcfa2f9f5 (t0301: fixes for windows compatibility, > 2021-09-14) explained, we should not call `mkdir -m` in the test > suite because that would fail on Windows (because Windows has a much > more powerful permission system that cannot be mapped into the simpler > user/group/other read/write/execute model). But in this case, we are emulating "mkdir -m 700" that is expressed in a very simpler world view of ugo=rwx with a much more powerful permission system, isn't it? If something is more powerful, it should be easy/possible to emulate a simpler system, I would naively think. In any case, a more productive than rethinking the "can we express what mkdir -m , which is a construct in a simpler world, wants to do in terms of a much more powerful permission system?" would be to see if the test linter can be taught about this particular rule. It is easy to forget that there is a platform we care about whose testing environment that emulates POSIX does not like "mkdir -m 700", and it is a bit too much to burden developers to remember. > There was one forgotten instance of this which was hidden by a `SYMLINK` > prerequisite. Currently, this prevents this test case from being > executed on Windows, but with the upcoming support for symbolic links, > it would become a problem. > > Signed-off-by: Johannes Schindelin > --- > t/t0301-credential-cache.sh | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh > index dc30289f75..6f7cfd9e33 100755 > --- a/t/t0301-credential-cache.sh > +++ b/t/t0301-credential-cache.sh > @@ -123,7 +123,8 @@ test_expect_success SYMLINKS 'use user socket if user directory is a symlink to > rmdir \"\$HOME/dir/\" && > rm \"\$HOME/.git-credential-cache\" > " && > - mkdir -p -m 700 "$HOME/dir/" && > + mkdir -p "$HOME/dir/" && > + chmod 700 "$HOME/dir/" && That "mkdir -p -m 700" is a no-no while "mkdir -p" followed by "chmod 700" is OK is a bit puzzling, but I assume $HOME does exist in the testing envioronment, so this new sequence should be equivalent in the simpler permission system. If it works fine on Windows, that is great. > ln -s "$HOME/dir" "$HOME/.git-credential-cache" && > check approve cache <<-\EOF && > protocol=https