possible gitattributes eol bug with new eol=crlf | lf support?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I start with a repository containing only four files:

  * lf.xml
  * lf.sln
  * crlf.xml
  * crlf.sln

The files whose names are prefixed by LF contain Unix LF EOL
characters. The files whose names are prefixed by CRLF contain Windows
CRLF EOL characters. Each file contains two lines, on one line 'jim',
the second line contains 'tim'.

I later add and commit a .gitattributes file containing the following rules:

  *.sln  eol=crlf
  *.xml eol=lf

I _then_ clone the repository and open each file in binary mode to find:

  * the crlf.xml file contains CRLF when it should contain only LF
<<<<<<< BUG ???
  * the crlf.sln file contains CRLF as it rightly should
  * the lf.xml file contains LF as it rightly should
  * the lf.sln file contains CRLF as it rightly should

Conversion of LF-EOL files to CRLF works fine, but conversion of CRLF
to LF fails to occur.

The doc is a little unclear if this is expected behavior, which if I
recall correctly from the email threads related to the new eol
support, this should not have occurred.

Guidance appreciated.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]