On Fri, Sep 30 2022, Tao Klerks wrote: > Hi folks, > > I just found out today both that icase magic exists (awesome!), and > that it isn't supported in ls-tree (boo). > > As far as I can tell, getting it supported would be the only way to > *efficiently* prevent caseless-duplicate files from being created in a > repo, in an "update" hook: I'd want to call ls-tree on the new head > commit for the branch, passing in an icase pathspec for all the files > being added since the previous state - and then sort and uniq. > > Of course, for entirely new branches I'd have to do a full check of > the tree, and for very large changes that might be the fastest/best > thing to do anyway, rather than creating a silly-sized pathspec - but > checking the full tree costs me about 1 second, a price that I'm loath > to pay for everyday commit verifications of a handful of files, vs a > 200,000-file full tree. > > I tried changing ls-tree "naively" to just permit the icase magic, > without any logic changes, and found at least one case where it > doesn't work: when combining wildcards with case-insensitivity, like > an icased "T/*" patchspec in the git repo; ls-files finds all the > tests, and a naively updated ls-tree does not. > > I think I see the last person to update this was Nguyễn Thái Ngọc Duy > in 2013, giving a hint as to what would need to be done to make this > be supported; is this an area anyone else might be looking at at the > moment? You might find ASCII-only sufficient, but note that even if you get this working you won't catch the more complex Unicode normalization rules various filesystems perform, see the fsck code we carefully crafted to make sure we don't get something those FS's will mistake for a ".git" directory in-tree.
