Re: What should be the CRLF policy when win + Linux?

From: Erik Faye-Lund <kusmabite@googlemail.com>
Date: May 6, 2010, 10:03 UTC
Message-ID: <k2x40aa078e1005060303xcd6aa177n73edc81e850d080e@mail.gmail.com>
In-Reply-To: <4BE28B6C.3070302@gmail.com>

On Thu, May 6, 2010 at 11:27 AM, mat <matthieu.stigler@gmail.com> wrote:

Show 7 quoted lines

> 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