> I don't imagine I can make a perfectly correct and universal fix to > this, but with case-insensitive matching on ls-tree in an update hook > I believe I could reduce the frequency of this already-infrequent > issue by at least 1000X, which would suit my purposes just fine. In my > case filenames are mostly ansi-based, and I don't expect we've ever > had Turkish filenames (turkish "i" being the most famous case-folding > gotcha I think?). How about doing it in something that's not ls-tree? Sounds like you already have a script, it just takes a bit too long? Something similar to On Fri, Oct 14, 2022 at 6:59 AM Torsten Bögershausen <tboegi@xxxxxx> wrote: > > For example, we can use Linux: > git ls-files | tr 'A-Z' 'a-z' | sort | uniq -d ; echo $? In a repo with many files, maybe use git diff --name-only and just run it periodically as a part of a check-in hook or something? git diff --name-only HEAD~100..HEAD | tr 'A-Z' 'a-z' | sort | uniq -d On Fri, Oct 14, 2022 at 9:59 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > git diff --diff-filter=A --no-renames --name-only $OLDHASH $NEWHASH | > sed -e s%/[^/]*$%/% | uniq | xargs git ls-tree --name-only $NEWHASH | > \ > sort | uniq -i -d Or what Elijah just wrote > Coming at this from another angle, I guess we could teach git on > case-insensitive filesystems to detect this situation (where two files > in the index, with different contents, are pointing to the exact same > filesystem file) and more explicitly warn the user of what's wrong, > giving them clear help on how to fix it? And temporarily exclude those > two files from its change reconciliation processes altogether to avoid > ghost changes interfering with recovery actions like "pull"? Certainly > that would be better than the current "ghost changes" behavior... but > it would still be far less convenient than preventing (the vast > majority of) these issues altogether, be that with a custom hook or a > core option prohibiting clearly case-insensitive-duplicate files from > being pushed. That's not to say this isn't a good idea but for now I'd advice an automated scripted route.
