Re: [boost] [conversion] Isolating the phantom file changes problem

Subject: Re: [boost] [conversion] Isolating the phantom file changes problem
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-25 17:55:20

On 26/11/2013 09:26, Quoth Beman Dawes:
> This is the simplest case I could come up with where git clone produced a
> initially modified state.
>
> Any ideas why this is happening? Is this another manifestation of crlf
> problems?

It would make sense.  .vcproj files would definitely get created with 
CRLF line endings, and SVG files probably would too if they were created 
with a Windows-based editor.  So it wouldn't be surprising if they were 
committed to SVN that way.

The conversion process needs to somehow ensure that only LF endings end 
up in the repository for files marked as "text" (or text="auto" that 
aren't obviously binary to git) in the .gitattributes, regardless of 
whether they had LF or CRLF endings in SVN.

If you're running the conversion from a Linux box, I think that means 
that you'll need to selectively dos2unix those files before committing 
them to git.

And as Steven Watanabe said, the svn:eol-style property is probably a 
good place to look to find potentially troublesome files.  In 
particular, what SVN does with svn:eol-style=CRLF is noticeably 
different from what git does with eol=crlf.

Shell scripts might benefit from being marked eol=lf in git, in case 
someone on Windows wants to run the script via Cygwin or MSYS.  There's 
probably no need to mark batch files or VS projects as eol=crlf, since 
these files are only likely to actually be used on Windows, and git 
should expand these to CRLFs just via "text" or "text=auto".