Hi Martin,
On Sun, 9 Jun 2019, Martin Ågren wrote:
> 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.
Oh my, you're right. I do not know how the filemode slipped in...
Thanks!
Dscho
> 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
>
