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
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".