On Sun, Oct 16, 2016 at 6:04 PM, Lars Schneider <larsxschneider@xxxxxxxxx> wrote: > Hi, > > Git attributes for path names are generally case sensitive. However, on > a case insensitive file system (e.g. macOS/Windows) they appear to be > case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That > works great until a Git users joins the party with a case sensitive file > system. For this Git user only files that match the exact case of the > attribute pattern get the attributes (only `foo.bar`). > > This inconsistent behavior can confuse Git users. An advanced Git user > could use a glob pattern (e.g. `*.[bB][aA][rR]) to match files in a > case insensitive way. However, this can get confusing quickly, too. > > I wonder if we can do something about this. One idea could be to add an > attribute "case-sensitive" (or "caseSensitive") and set it to false > (if desired) for all files in .gitattributes for a given repo. FYI: I am currently refactoring the attr subsystem (e.g. https://public-inbox.org/git/20161012224109.23410-1-sbeller@xxxxxxxxxx/ "attr: convert to new threadsafe API") > > ### .gitattributes example ### > > * case-sensitive=false Would this modify the current file only or the whole stack of attrs? (In just one way or the whole stack, i.e. can you add this in .git/info/exclude and the attribute file in the home dir also behaves differently? Or rather the other way round when the system wide attr file enables case insensitivity, each repository local config is set automatically? both ways?) > *.bar something > > ### > > I haven't looked into the feasibility of an implementation, yet. However, > would that be an acceptable approach? Conceptually I would prefer if we had a single switch that indicates a case insensitive FS. That could be used for different purposes as well, that are FS relevant such as checking in, checking out/renaming files in the working tree? (does any such switch already exist for case sensitivity?) Thanks, Stefan > > Thanks, > Lars > > >