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

From: Martin Ågren <martin.agren@gmail.com>
Date: Jun 9, 2019, 19:23 UTC
Message-ID: <CAN0heSrQ-AVui0OzpL7WGBzmdU4ignUsFxYqeXDtgR+CsDXbJw@mail.gmail.com>
In-Reply-To: <1dd56d034efb6ff251bdac8d099052175f4777a0.1560005022.git.gitgitgadget@gmail.com>

Hi Dscho,

On Sat, 8 Jun 2019 at 16:45, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote:

Show 7 quoted lines

>
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible
> that the idea Bash has of the current directory differs in case from
> what Git thinks it is. That's totally okay, though, and we should not
> expect otherwise.

> +downcase_on_case_insensitive_fs () {
> +       test false = "$(git config --get core.filemode)" || return 0

I think it would be worthwhile to add `--type=bool` to this git-config call. See, e.g., the FILEMODE prereq in t/test-lib.sh. From my understanding, this check would regress if someone did s/false/no/ in builtin/init-db.c, so this check is perhaps not as robust as it could be. (Now, as for *why* someone would do such a change...)

I do wonder if this is the right way to check for a case-insensitive filesystem. According to git-config(1), this variable tells whether "the executable bit of files in the working tree is to be honored". I can see how this property could correlate with the filesystem being case-insensitive, but from git-config(1), I would have expected core.ignoreCase to be queried instead.

You're no doubt a lot more familiar with filesystem case-insensitivity and how it interacts with Git than I am. Any light you could shed on this would be much appreciated.

> +       for f
> +       do
> +               tr A-Z a-z <"$f" >"$f".downcased &&
> +               mv -f "$f".downcased "$f" || return 1

Makes sense. Good error-handling.

> +       done
> +}

Cheers Martin