On 18. aug. 2010, at 16.14, Will Palmer wrote: [...] > 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. "core.autocrlf" now does something like this: it only converts a file if it contains no CRs in the repository. The downside to this behaviour is that line endings are no longer normalised, but since normalisation never worked very well as a configuration setting, that's a worthwhile tradeoff. The attributes are used to enable normalisation unconditionally, and this _should_ be okay since they are versioned along with the contents of the repository so those contents _should_ reflect the attributes' settings. Unfortunately, as you discovered, this isn't necessarily true in older repositories. Fortunately, as Thomas Rast noted elsewhere, .git/info/attributes can work around the problem. [...] >> 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. "rm .git/index && git reset" usually does the trick for me. If the index is intact, git will know that you haven't touched any files and won't bother to check them. [...] >> 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. I don't see how refusing to check out would be helpful. How would you recover from that? I think git does the least it can in this situation: no files are modified in any way, but the user is notified that some of them will be modified if they are "git add"ed. If they are then committed, the problem is solved and future checkouts _will_ be "pristine". In your case, simply committing the normalised files isn't an option since some of them are binaries and will be corrupted, so modifying .gitattributes is the way to go there. [...] > 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. Hopefully, the owner of the repository will at least remove the error from future versions, if not actually filter it out of existence. But it _is_ an error, it's just that prior to git 1.7.2 only people with autocrlf set could see it. I did consider this as a potential problem when implementing the new crlf conversion behaviour, but reasoned that very few repositories would be affected in this way: there was no reason to set the crlf attribute unless you worked with people who had core.autocrlf set, and if you did, they would notice the spurious "modifications". I'm sorry you hit a repository with an incorrectly set crlf, and I hope there aren't many more out there. - 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