On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey <rcdailey.lists@xxxxxxxxx> wrote: > Upon inspection of the gitattributes documentation page here: > https://git-scm.com/docs/gitattributes > > When comparing the documentation for 'text' with 'eol', I see the > following missing explanations for 'eol': > > * eol > * -eol > > Maybe the fact that these are missing means they are not valid to use. > There is also the issue that `text` usually controls EOL anyway. Is > there ever any reason to set eol in a way differently than explained > in the documentation (that is, `eol=lf` or `eol=crlf`)? > > For example, what if you want a file to be treated as text BUT you do > not want it to perform EOL normalization at all. Could you do this? > > foo.txt text -eol > > Just at first glance, this to me would mean line endings on checkin > and checkout are not touched (CRLF could be checked in). Is this > possible? > > What about setting `eol` but not `text`? > > Honestly it seems like `eol` is just a supplementary setting for > `text` and was never intended to be used in ways that are > undocumented. Some explanation to help uncloud this would help, or > maybe I missed something in the documentation that explains this. I did a few tests out of curiosity: * eol This allowed CRLF to be committed in a file named `foo.txt` (I saw ^M in the diff, which I think means CR character, and treats this character as an error) * text=auto eol This did not differ in behavior from `* text=auto` from what I could see. It removed CR characters in the repository on check in. * text=auto -eol Same as before, the addition of `-eol` did not change the behavior at all. So yeah, I'm still horribly confused. None of these scenarios make any sense. The only time I ever set `eol` explicitly is to either do `eol=lf` or `eol=crlf`. -- To unsubscribe from this list: send the line "unsubscribe git" in