The gitattributes documentation (e.g. from "git help attributes")
gives the impression that the "text" attribute's sole effect is to
control whether or not end-of-line normalization takes place. I wanted
to check whether I'm indeed supposed to take such a narrow
interpretation as a git user, or whether setting "text" or "-text"
might have a broader meaning (or whether it will have a broader
meaning in the future).
In the rest of this message, let me outline a case of current interest
where the distinction seems to matter:
I'm starting a new repository for a Windows-only project where I don't
think I want git to do any end-of-line normalization on my text files.
(I'm totally happy to have CRLFs both in the repo and in all the
working copies.) Unless you think that end-of-line normalization is
always vital, let's try to presume I've made the right choice about
this.
Now as far I can tell from the gitattributes documentation, one
perfectly legitimate way to accomplish this (and to override any
core.autocrlf settings on other teammates' machines in the process) is
to add a .gitignore file to my repo containing the single line
* -text
If all "-text" does is disable end-of-line normalization, then this
setting should be a small deal. For example, it shouldn't
fundamentally alter how any of the source control operations (diffs,
merges, etc.) work on my text files, or generate more merge conflicts
than otherwise. (Recall that I'm starting a fresh repo, so I don't
have to worry that the repo might already have some normalized
linefeeds.)
But I'm not completely sure if it's reasonable to expect there to be
no side-effects. I haven't yet discovered any side-effects from git
itself, but I have at least discovered one in the Git Extensions
project, which takes a broader interpretation of "-text". Some of you
might not care directly about Git Extensions, but perhaps you can
still help me figure out whether I'm making a misguided use of
"-text", or whether this is perhaps an area where Git Extensions is
doing the wrong thing:
* Here's the normal behavior (without "* -text"): Git Extensions has a
widget that lets you explore a given commit. In that widget, if you
click on the name of a text file, then the contents of that file shows
up in an adjacent pane. In contrast, if you click on the name of a
binary file, then the adjacent pane simply says, e.g., "Binary file:
foo.jpg".
* Here's the behavior with "* -text" in my .gitattributes: Now, no
matter what file I click on in the above widget, the pane says, e.g.,
"Binary file: foo.txt". I can no longer see the contents of any text
files, which is annoying.
* I peeked at the Git Extensions code, and it is making the following
inference: The path to foo.txt is tagged as "-text", therefore the
file is "binary", therefore it doesn't make sense to display its
contents to the user, and therefore I'll just display "Binary file:
foo.txt" instead. But this is an unfortunate consequence. When I
originally set "-text" I didn't mean to convey "this is a binary
file", merely "don't mess with newlines."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html