git - problem with EOL formats working with git svn

eantoranz · 06-19-2015, 05:47 PM

Hi!

I'm cloning an svn project on git (on windows, using cygwin). It's going through all the branches, the process is going smoothly. I want to make sure git doesn't mess with EOL formats of the files in any way so I configured git to have core.autocrlf to be input (which means that git won't mess with the files), right?

Code:

$ git config -l
user.name=whoever
user.email=whoever@example.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.autocrlf=input
core.longpaths=true

# git svn configuration is over here, no point in adding it over here

I check out some revision. Here's where the funny thing starts.

- I ask git for status. It tells me that some (not many, fortunately, but some) files have changed. I diff one of them, it tells me that it has changed EOL format (whole file replaced with the same content, according to diff). To make sure if the file is the same, I do a sha1sum of the file as it is on the repository on this version (git show revision:filepath | sha1sum -), do the sha1 as it is on the FS and it is the same thing. Also on svn, the sha1 is the same thing. Why is git telling me that the file has changed then?

- So, core.autocrlf is set to input, right? Then why does git tell me this when I add the file as a test (without any changes whatsoever)?

Code:

$ git add somepath
warning: CRLF will be replaced by LF in somepath.
The file will have its original line endings in your working directory.

Thanks in advance.

Code:

$ git version
git version 2.1.4

ntubski · 06-20-2015, 04:23 AM

What you want is core.autocrlf = false, see Mind the End of Your Line:

Quote:

core.autocrlf = false This is the default, but most people are encouraged to change this immediately. The result of using false is that Git doesn't ever mess with line endings on your file.

This isn't even mentioned in the manual, I guess it's supposed to be obvious

As mentioned in that article, you can instead use the "new system": put

Code:

* -text

into .gitattributes, which has the advantage of working even for other people who don't have the right core.autocrlf setting.

Quote:

Originally Posted by eantoranz

I'm cloning an svn project on git (on windows, using cygwin). It's going through all the branches, the process is going smoothly. I want to make sure git doesn't mess with EOL formats of the files in any way so I configured git to have core.autocrlf to be input (which means that git won't mess with the files), right?

Mind the End of Your Line

Quote:

core.autocrlf = input This means that Git will process all text files and make sure that CRLF is replaced with LF when writing that file to the object database. It will not, however, do the reverse. When you read files back out of the object database and write them into the working directory they will still have LFs to denote the end of line.

The manual tersely explains this:

Quote:

core.autocrlf

...This variable can be set to input, in which case no output conversion is performed.

From which we're supposed to infer that input conversion is performed.

eantoranz · 06-20-2015, 09:50 AM

Oh... I see... A little more experimentation is required then. Thank you for your feedback. Will let you know how it goes on monday.