Issues with line-endings and autocrlf setting after SVN to Git transition

Issues with line-endings and autocrlf setting after SVN to Git transition

[Bradley Wagner]

So I'm running into the infamous issue with line-endings after
migrating an SVN repo to Git.

I'm on OS X and I currently have auto.crlf set to "input" as
recommended on this GitHub page:
http://help.github.com/dealing-with-lineendings/. I'm doing a fresh
clone of our repo and it's showing many files as having changed.

I've gotten conflicting answers to my question on Stack Overflow:
http://stackoverflow.com/questions/3161797/will-the-fix-to-correct-line-endings-in-git-repositories-make-future-diffs-usel.
Should I fix this with a commit or turn off autocrlf? I intend to use
this repo in both OS X and Windows environments. The problem with
fixing it with a commit is that the commit will change every single
line of these affected files. As I understand it from SVN, this means
that any diffs that span that commit will basically show the entire
files as being changed which is definitely frustrating.

Re: Issues with line-endings and autocrlf setting after SVN to Git transition

[Eyvind Bernhardsen]

On 2. juli 2010, at 21.59, Bradley Wagner wrote:

> So I'm running into the infamous issue with line-endings after
> migrating an SVN repo to Git.
> 
> I'm on OS X and I currently have auto.crlf set to "input" as
> recommended on this GitHub page:
> http://help.github.com/dealing-with-lineendings/. I'm doing a fresh
> clone of our repo and it's showing many files as having changed.

That GitHub page is noble, but wrong: setting core.autocrlf gets you into trouble when you clone a repository that already has CRLFs, as you have found.

The upcoming 1.7.2 version of git adds a safety feature to autocrlf that makes it ignore files that already have CRLF in the repository.  You will be able to use autocrlf without getting the spurious changes, but it will no longer convert files with "wrong" line endings already in the repository.

> I've gotten conflicting answers to my question on Stack Overflow:
> http://stackoverflow.com/questions/3161797/will-the-fix-to-correct-line-endings-in-git-repositories-make-future-diffs-usel.
> Should I fix this with a commit or turn off autocrlf? I intend to use
> this repo in both OS X and Windows environments.

It depends what you want, but right now I suggest turning autocrlf off and living with the mixed line endings.  Once git 1.7.2 is released you can start using autocrlf to get CRLF on Windows, as long as you don't mind the mix of LF and CRLF files on OS X.

> The problem with
> fixing it with a commit is that the commit will change every single
> line of these affected files. As I understand it from SVN, this means
> that any diffs that span that commit will basically show the entire
> files as being changed which is definitely frustrating.

"Diff" and "blame" can be told to ignore changes in whitespace, but the real problem with doing a conversion like this using (old) autocrlf is that checking out versions from before the conversion will still show lots of changes.

This is where the other normalization feature introduced in 1.7.2 comes in.  Marking a file with the "text" attribute tells git to normalize its line endings, and the attribute can be set to "auto" for all files if you want automatic conversion.  A configuration variable lets you set which line endings you want in your working directory.  Older versions are not affected since it is an attribute, so you won't get spurious changes when you check them out.

So if you want to normalize line endings in your repository, wait for git 1.7.2 and then read up on the "text" attribute.
-- 
Eyvind