Re: possible gitattributes eol bug with new eol=crlf | lf support?
On 12. sep. 2010, at 21.58, Robert Buck wrote:
> Thanks Eyvind,
>
> I tried it on an experimental repository and it worked. Thank you for
> your recommendation.
Show 9 quoted lines
> I also found the following link at github which achieves a similar
> effect. Adding this for the record in case someone else searching for
> a solution in the future wanted more detail.
>
> http://help.github.com/dealing-with-lineendings/
>
> The one thing I find curious about the github article is that it seems
> to recommend using autocrlf=true for ALL platforms once the linefeeds
> have been normalized.
That article hasn't been updated for 1.7.2, but what it's saying is that line ending normalisation should be enabled for all users (or none) if you want to avoid problems.
The point of the text attribute is to allow you to enable or disable line ending normalisation without the user having to configure anything; setting the attribute "text=auto" on all files is equivalent to every user manually setting autocrlf to "true" or "input" in that repository.
[...]
> So if we did this one-time normalization on all repositories, all
> branches, what holistic approach (eol, autocrlf) would keep our files
> sane for a mix of 1.7.2 and later, and 1.7.0.1 and earlier, Windows,
> Mac, and Linux?
I would set the text attribute to auto for all files (add the line "* text=auto" to .gitattributes) to take care of users with git 1.7.2 or newer. Users with older versions of git should set autocrlf=true (Windows) or autocrlf=input (Mac and Linux).
Once all users are upgraded to newer versions of git you can change the normalisation to target only specific files or file types, but that's not advisable while any of your users have autocrlf enabled.
- Eyvind
Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>