.gitattributes text attribute does not work properly on Windows if autocrlf is not true about git HOT 11 CLOSED

There has been some upstream-work on this:

http://mid.gmane.org/20100904082509.GC10140@burratino

The problem seems to be that NATIVE_CRLF is only set for the MSVC build, and not the MinGW-build. The patch there doesn't seem to have been picked up yet, though. And as things are now, the hunk needs to be against config.mak.uname instead of Makefile.

from git.

Seems like this patch has now been applied upstream (though I do not see the changes yet in any of the upstream repositories). I'm leaving this open until we get the fix with the next rebasing merge of upstream.

from git.

@sschuberth I think it's this commit.

from git.

@taspeotis Right, that is the upstream commit which will be part of upstream Git 1.8.3, but we do not have that commit in our Windows fork yet.

from git.

Odd, I still see this issue in Git for Windows 1.8.3 although we now have NATIVE_CRLF = YesPlease in config.mak.uname for the MINGW build.

from git.

Ah - I noticed this during testing 1.8.3. I have a branch on github called pt/native-crlf where I actually push that flag to the compiler so it can have an effect. However, it introduces a few new failures in the test suite and I elected not to include that in the release. I guess making it a pull req might tie it into this bug somehow.

from git.

Fixed on master.

from git.

I think that instead of these code changes, it would be better to change the docs to read:

This ensures that all files that git considers to be the text will have normalized (LF) line endings in the repository. If core.autocrlf=true, core.eol will be used to normalize the files in your working directory. core.eol defaults to native line endings for your platform.

I blogged about this just now.

from git.

Without the code-changes, that last sentence would be wrong.

from git.

True, but the sentence before it isn't correct with the changes. I think it would be best if the spec was clarified what the behavior should be. I think it would be best if the working directory matched what is in the repository by default.

I did a bunch of testing a filled a spreadsheet full of tests.

from git.

I think it would be best if the working directory matched what is in the repository by default.

If that we the case, Windows users would commit new files with CRLF by default, and Linux users would commit new files with LF by default. That's certainly not a good idea for a cross-platform project on which developers from multiple host OSes work.

Anyway, the discussion is going a bit off-topic here. There original issue is resolved, and Git for Windows now works as currently specified. If you want to discuss whether the current specification makes sense, please take that discussion to the upstream Git mailing list.

from git.