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

["Martin Ågren" <martin.agren@gmail.com>]

Hi Dscho,

On Sat, 8 Jun 2019 at 16:45, Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> 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