Re: [PATCH 1/1] t0001: fix on case-insensitive filesystems
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
Johannes Schindelin via GitGitGadget
