On Wed, 2010-08-18 at 15:18 +0200, Eyvind Bernhardsen wrote: > 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. I don't know when the .gitattributes file was added, surely git should account for varied settings over time, especially when the meanings of those settings have changed over time? Something like "only apply when there are other changes to this file", or only when the newline-status of the file itself has otherwise changed, for that matter. > > > 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. So how do I tell git that I don't want those files to be modified? How do I tell git "discard all local changes, even those which some random file has asked you to make"? > > > 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. This was one of the first things I tried, but with no luck. Perhaps there is some extra step involved to tell git "update the working copy using the new setting"? I have tried both git checkout --force HEAD, and git reset --hard HEAD, but neither seem to have an effect. > > > 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. How about an "ignore .gitattributes" option? Or a "use alternative .gitattributes" option? This is not my repository. I don't have control over what's in it, and while I expect I'll be maintaining a local patchset, I don't really want to maintain patches of the "my git is more-broken than the upstream's git" variety. > > > 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. "pristine" to me means "no changes". If there is an inconsistency which git doesn't like, git should complain about that, refuse to checkout, declare "broken repository! Oh no!" and refuse all operations, etc. It git can determine that it is unable to act in a sane manner, I don't want git to just go ahead making wild guesses. > > > 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. Just to re-state: This is not "my repository". That is, I don't consider it to be. So I would prefer only solutions which involve editing something unversioned, such as .git/config, rather than making random patches which feel very much like work-arounds to a git problem. If it were "my repository", and there were some problem like this, then I would probably use filter-branch to remove the error from history. > > - Eyvind - Will -- 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