On Thu, May 6, 2010 at 11:27 AM, mat <matthieu.stigler@xxxxxxxxx> wrote: > Thanks for your answer!! > > I think what you suggest Ramkumar is indeed what I need, great! The > suggestion from hasan to keep with those settings was not doable as the > windows guy had the problem of that after even a clean cloning, git was > signaling changes (see: http://help.github.com/dealing-with-lineendings/) > This is a symptom that someone checked in files with CRLF into the repo with core.autocrlf disabled, and the Windows guy having core.autocrlf enabled. I don't quite agree with Hasen about checking out LF on Windows, though. There's just too many tools that gets slightly confused (as well as some getting REALLY confused) by this in my experience. It's sometimes the best trade-off, but quite often not IMO. What I'd do, is to set core.autocrlf to "input" on non-Windows machines, and "true" on Windows-machines. This makes sure that no machines will check in CRLF. If there's already files checked in with CRLF (as seems to be the case with your repo), the Windows-people will be annoyed. So you'd need to make sure that the repo only contained CRLFs, and you have basically two options: 1) Just call dos2unix on all files and commit the changes. This will still cause problems for the Windows users if they need to check out commits older than the dos2unix one. 2) Use git filter-branch to rewrite the history to pretend no one ever made the mistake of committing CRLFs. This will make trouble for anyone who's working on a branch. But it's a one-time issue (unless someone manages to commit CRLF-files again, that is). -- Erik "kusma" Faye-Lund -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html