Re: [PATCH 05/10] t0301: another fix for Windows compatibility

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 1, 2025, 13:25 UTC
Message-ID: <e355d80a-a0e9-7795-06cd-1b8acfa6c7c8@gmx.de>
In-Reply-To: <xmqqikescar1.fsf@gitster.g>

Hi Junio,

On Sat, 29 Nov 2025, Junio C Hamano wrote:

Show 16 quoted lines

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > Just like 0fdcfa2f9f5 (t0301: fixes for windows compatibility,
> > 2021-09-14) explained, we should not call `mkdir -m<mode>` 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.

It is probably outside the purview of this patch series to question why Cygwin's `mkdir -m` doesn't emulate Unix semantics let alone to fix it. So I'll bow out of that tangent.

> In any case, a more productive than rethinking the "can we express
> what mkdir -m <mode>, 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.

Seeing that this issue had to be fixed twice within the course of over 4 years, https://xkcd.com/1205/ applies.

Ciao, Johannes

Show 37 quoted lines

> 
> 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 <johannes.schindelin@gmx.de>
> > ---
> >  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
>