Hi Dscho,
On Sat, 8 Jun 2019 at 16:45, Johannes Schindelin via GitGitGadget
<gitgitgadget@xxxxxxxxx> wrote:
>
> From: Johannes Schindelin <johannes.schindelin@xxxxxx>
>
> 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
