Re: [PATCH v2] t4126: make sure a directory with SP at the end is usable

[Jeff King <peff@peff.net>]

On Thu, Mar 28, 2024 at 07:18:52PM -0700, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > +test_expect_success 'parsing a patch with no-contents and a funny pathname' '
> >  	git reset --hard &&
> > +	empty_blob=$(test_oid empty_blob) &&
> > +	echo "$empty_blob" >expect &&
> >  
> > +	git update-index --add --cacheinfo "100644,$empty_blob,funny /empty" &&
> 
> It seems that on Windows, this step fails with "funny /empty" as
> "invalid path".
> 
> https://github.com/git/git/actions/runs/8475098601/job/23222724707#step:6:244

Ah, sorry, I didn't actually try my suggestion on Windows. I guess we
are falling afoul of verify_path(), which calls is_valid_path(). That is
a noop on most platforms, but is_valid_win32_path() has:

                  switch (c) {
                  case '\0':
                  case '/': case '\\':
                          /* cannot end in ` ` or `.`, except for `.` and `..` */
                          if (preceding_space_or_period &&
                              (i != periods || periods > 2))
                                  return 0;

I'm mildly surprised that we did not hit the same problem via "git add".
But I think it does indeed call verify_path(). It's just that the
filesystem confusion prevented us from even seeing the path in the first
place, and we never got that far.

It's interesting that there is no way to override this check via
update-index, etc (like we have "--literally" for hash-object when you
want to do something stupid). I think it would be sufficient to make
things work everywhere for this test case. On the other hand, if you
have to resort to "please add this index entry which is broken on my
filesystem" to run the test, maybe that is a good sign it should just be
skipped on that platform. ;)

-Peff