On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey <rcdailey.li...@gmail.com> 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
