Re: [PATCH 1/1] t0001: fix on case-insensitive filesystems

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 19, 2019, 20:17 UTC
Message-ID: <nycvar.QRO.7.76.6.1906192201200.44@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqo935o0yi.fsf@gitster-ct.c.googlers.com>

Hi,

On Mon, 10 Jun 2019, Junio C Hamano wrote:

Show 11 quoted lines

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> >>  test_expect_success 'init with separate gitdir' '
> >>  	rm -rf newdir &&
> >>  	git init --separate-git-dir realgitdir newdir &&
> >>  	echo "gitdir: $(pwd)/realgitdir" >expected &&
> >> +	downcase_on_case_insensitive_fs expected newdir/.git &&
> >
> > I wonder if there's maybe a simpler way. If we canonicalize paths when
> > writing them to the gitdir file, then writing "$(pwd -P)" on the line
> > above should produce the right result.

When you execute `pwd -P` in Git for Windows' SDK's Bash (which is an MSYS2 Bash), you get the emulated Unix path. For example, in my main Git worktree, this results in

	$ pwd -P
	/usr/src/git

However, the actual (i.e. Windows) path seen by `git.exe` is `C:/git-sdk-64/usr/src/git`.

> > Now, technically, POSIX doesn't require case canonicalization of the
> > path with "pwd -P", but then again, POSIX doesn't permit
> > case-insensitive file systems,

I was not sure about this statement (that POSIX does not permit case-insensitive file systems), so I whipped up this gem in a quick web search (https://unix.stackexchange.com/a/358407):

	According to the POSIX specification:

	    The system may provide non-standard extensions. These are
	    features not required by POSIX.1-2008 and may include, but are
	    not limited to:

	--snip--

		Non-conforming file systems (for example, legacy file
		systems for which _POSIX_NO_TRUNC is false,
		case-insensitive file systems, or network file systems)

Which means that I now know once and for all that POSIX does not dictate whether a file system should, or should not, be case-insensitive.

> > and we know the behavior on macOS uses bash, which does the right
> > thing in this case because it calls realpath(3). I've tested that it
> > also does the right thing on Linux when the worktree containing the
> > Git checkout is in a path with symlinks.

I am honestly not a big fan of relying on testing things on the major three platforms and then assuming that everything will work also on the long tail of operating systems/setups.

That is exactly the kind of thinking that led me to believe that relying on REG_STARTEND was a sane thing, and it simply wasn't. It caused quite a bit of pain, and my original approach would have prevented that, and after testing on the major three platforms I let myself be talked into dropping the original approach.

Show 6 quoted lines

> > I don't know how that works on Windows, but if it does, it might be
> > simpler.
>
> Yup, it would be a worthwhile avenue to pursue; on the negative
> side, a single-liner "no, unfortunately that would not work on
> Windows" would also be useful.

1) no, unfortunately that would not work on Windows. In a PowerShell, when
   I call `c:` followed by `cd \GIT-SDK-64`, it reports the current
   directory as `C:\GIT-SDK-64` (i.e. with the wrong case, the real name,
   on disk, is `C:\git-sdk-64`). When I then call Git's Bash to execute
   `git -PW` (the `W` stands for: gimme a Windows path), it reports
   `C:/GIT-SDK-64`. Incorrect case.

2) It might look more elegant from the design perspective, but oh my
   goodness do I not want to be a developer who has no knowledge of this
   design decision, being tasked to debug any related issue.

   It would be very "magic" that Git relies on its having written a
   normalized path, not dealing well with Git worktrees initialized by
   alternative Git implementations that did not normalize that path, or
   previous Git versions that also did not, for example.

   And normalizing the path for the sake of having this test case pass?
   Nah. I like it explicit. And that's what my patch does. No magic.

Ciao, Dscho