Is "git checkout --patch" incompatible with autocrlf=true?

user_50225 0
Viewed 79

On my windows machine I'm considering setting autocrlf = true in my .gitconfig. Others on my team have it set this way and we've ended up with a mix of lf & crlf in the repo. I've considered a few options and this seems like the path of least resistance...

One thing I've noticed is that git checkout -p fails with the error patch does not apply when autocrlf = true. If I change it back to false it works as expected.

Is autcrlf = true incompatible with checkout --patch or is do I need to set some other option to get it to work?

Interestingly git add --patch works as expected with autocrlf = true.

windows git
1 Answers

Yes, git checkout --patch works properly with line ending translation. The patch almost certainly isn't applying because you have mismatched configuration.

Everybody on your team needs to use the same line ending configuration. core.autocrlf=true isn't an option that one person on a team can enable; everybody needs the same settings. That's because if you have core.autocrlf=false, then you're telling Git that the contents on disk are identical to the contents in the repository. If you're on Windows, that means that you're checking in files with Windows-style line endings (\r\n). If you have a colleague who enables core.autocrlf=true, then you're telling Git that the contents on disk have Windows-style line endings while the contents in the repository have Unix style line endings (\n).

But your colleague has told git a lie, since the repository contents actually have \r\n in them.

A variety of strange things can occur when these settings are mismatched, including things like patches failing to apply.

You should instead:

  1. Set * text=auto in your .gitattributes file. This ensures that everybody working in the repository has the same settings, since the configuration is actually checked in and not something that everybody has to remember to configure properly.

  2. Renormalize the repository, so that the repository contents actually match what you've claimed. You can do this by git add --renormalize . and checking the contents in.

Once you've done this (and everybody has updated your local working folders), your git apply --patch should behave correctly.

user_7298810
Related