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