Hi Alexander, Yeah, I've done that. I actually found two different ways to do it. The first [1] was:
$ rm .git/index # Remove the index to force git to $ git reset # re-scan the working directory $ git status # Show files that will be normalized $ git add -u Which found a bunch, so I committed locally. Then I found [2]: $ git rm --cached -r . git reset --hard git add . This took longer to run, but - gratifyingly - it found no files changed. Let me know if there's something I haven't done that should've. Cheers Dan [1] http://christoph.ruegg.name/blog/2011/7/30/cleaning-up-after-migrating-from-hg-to-git.html [2] https://help.github.com/articles/dealing-with-line-endings On 4 December 2012 22:56, Alexander Krasnukhin <[email protected]>wrote: > Have you normalized the whole repo first? If you still have some files in > CRLF style or even with mixed CRLF & LF style you will have some fun with > them later. Nothing crucial but sometimes *very* confusing. > > > On Tue, Dec 4, 2012 at 11:36 PM, Dan Haywood > <[email protected]>wrote: > > > All, > > > > just an fyi, I've just pushed a commit so that our line endings are > > normalized to unix-style LF in the git repo. > > > > For those who use Windows, git can be configured to automatically convert > > LF to Windows-style CRLF on checkout, and back again to LF on checkin. > > > > This is traditionally done by running the "git config core.autocrlf auto" > > command (as documented on our site [1]), and it certainly doesn't harm to > > run that command. However, I've also checked in a .gitattributes file > that > > takes precedence over this config setting. The file specifies what > should > > be considered as text (eg .java, .xml) and what as binary (eg .png). > It's > > worth being aware of this file and adding in entries for new file binary > > types. > > > > Thx > > Dan > > > > [1] http://isis.apache.org/contributors/using-git.html > > > > > > -- > Regards, > Alexander >
