On 18. aug. 2010, at 14.40, Will Palmer wrote: > I am on Linux, and core.autocrlf is not set. .gitattributes in the > JQuery repository contains: > * crlf=input That's a strange setting; in older versions of git, it means something like "if core.autocrlf is enabled, only convert CRLF on input"; that is, it effectively turns core.autocrlf=true into core.autocrlf=input. I'm not sure why anybody would want that. In any case, it doesn't appear to have prevented CRLFs from entering the repository, which is what's causing the behaviour you see. > Bisect reveals: > fd6cce9e89ab5ac1125a3b5f5611048ad22379e7 v1.7.0-3-gfd6cce9 > Add per-repository eol normalization > > is the first git commit which shows this problem. That's because from that commit, "crlf=input" turns on autocrlf implicitly (it is equivalent to "eol=lf"). Previously, the crlf attribute would only have an effect with core.autocrlf turned on. > I am confused as to why I am seeing what I am seeing, though. I was > under the impression that "crlf=input" meant: "convert crlf to lf on > input", which I would take to mean that it would never have any effect > whatsoever on "git status"'s output. Files containing CRLFs in your repository keep the CRLFs in the working tree. If you check them in now git will convert CRLF to LF, so they are marked as modified. > If I clone using a version of git before v1.7.0-3-gfd6cce9, then "git > status" from a newer git, then everything also appears to work normally > (though I haven't dug much into this aspect) If you turn on core.autocrlf=input or core.autocrlf=true you should get the same behaviour with older gits as well. Note that msysgit has had autocrlf enabled by default for years, so no positive action is required to do this. > Is there a git option for "just give me what's in the repository, don't > ever perform any conversions, one way or the other, just act sane" ? Not with that .gitattributes :) If you don't want conversion, don't set the crlf, eol or text attributes. > I thought I had finally understood all this autocrlf nonsense, but once > again I see this as being only an "act stupid mode". I have no idea > what's going on here, and I just want to be able to rely on the > following: > - git clone someproj.git && cd someproj && git status; > should NEVER report changes > - git reset --hard HEAD && git status; > should NEVER report changes > > and, why I ran into this situation this time around: > - git clone someproj.git && cd someproj && git checkout sometag; > should ALWAYS work > > Can anyone explain why these aren't valid assertions? If they're not, > then what is the proper way to tell git "give me a real pristine copy"? Git _is_ giving you a real pristine copy, it's just informing you that your repository is not consistent with the attributes you have set. > Below is a log of the problem in-action. [...] > # modified: build/google-compiler-20091218.jar > # modified: build/js.jar Heh. I was about to ask if there was anything funny about these presumably binary files, but then I realized that .gitattributes is forcing crlf=input for _all_ files. I suggest removing the crlf setting from .gitattributes. - Eyvind -- 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