On 17/10/16 05:07, Stefan Beller wrote:
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`).
This feels like a bug:
$ git diff
diff --git a/.gitattributes b/.gitattributes
index 5e98806..1419867 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,3 +1,4 @@
* whitespace=!indent,trail,space
*.[ch] whitespace=indent,trail,space
*.sh whitespace=indent,trail,space
+*.C text
-----------
$ git -c core.ignorecase=false check-attr --all git.c
git.c: whitespace: indent,trail,space
#But running on a case insensitve FS I get:
$ git check-attr --all git.c
git.c: text: set
git.c: whitespace: indent,trail,space
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
How about
* ignorecase=true
?
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