2

Just moved to git and encountered a problem which has been discussed in detail here

I wanted to understand given that we have set core.autocrlf=true by default and we deal with vast amount of java i/o and consequently have various test cases for the same ; how can we ensure that unit test cases developed by a dev on win can execute correctly for a dev on linux and vice versa.

for eg. a unit test case reads in a text file (*.ext) and compares the length of the bytes as expected vs actual then on win ; a git pull with core.autocrlf=true will have pulled in the text file and converted all LF to CRLF . Consider for instance the test case is interested in the byte count and thus on win the byte count will be more. On commit the CRLF wud be converted to LF ; but the test wud then fail for the dev on linux.

Can this managed with .gitattributes ?

In .gitattributes -> *.ext text

this would normalize the file on commit and will still suffer from the above problem ? Pointers welcome, Thanks in advance

sunny
  • 824
  • 1
  • 14
  • 36

1 Answers1

1

As I have said before, never set core.autocrlf to true, always to false.

It is a global setting with unintended consequences.

If you have certain type of documents you want to manage in term of eol, do so only through .gitattributes files and core.eol directives.

In your case, gitattributes are a good solution in order to have a fine-grained control on what you want to be converted.

But the general idea is to not convert anything until it is absolutely necessary:
If you can generate or store those text files (used for testing) with the right eol (whatever the underlying OS is), your test cases will be consistent.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • "if you can gen or store those txt files with the right eol" ... I would want to use git to enable that cause modifications in one os would lead to failures on another. do you have suggestions for managing this ? – sunny Sep 11 '13 at 05:43
  • 1
    @sunny I meant generating the txt files with only one eol style, and keeping that eol across OSes, meaning no `core.autocrlf`, no `.gitattributes core.eol`, no conversion at all. Meaning the tests would behave consistently. – VonC Sep 11 '13 at 05:51
  • understood. so that would become a dev best practice rather than a solution through git – sunny Sep 11 '13 at 05:57
  • @sunny yes, in my experience, always try to limit the conversion until you *absolutely* need it. – VonC Sep 11 '13 at 06:08
  • accepting this as the answer. a failure can be easily caught in automated test builds and be fixed. a pain that can prolly be lived with. – sunny Sep 12 '13 at 18:08