When .gitattributes is updated to mark that certain files must contain certain line endings, those files become "due" for an update. But git allows .gitattributes to be committed without updating those files to match. In fact, it won't even tell the committer that they've just made some files "stale" in this way. The problem is that when there are files that are pending such a line endings update, git behaves very badly. In particular, one gets modified files that absolutely cannot be reverted, and (a much worse problem) some merges become impossible: you start with a clean checkout, run a merge, and then git decides that your checkout wasn't clean after all. The solution is simple: commit a change that fixes all the line endings. But until this is done, the repo is pretty broken. REQUEST Don't let the repo get into this state in the first place. Or at least not without a "--force" flag. Basically, if a commit contains a .gitattributes change, I'd like git to check whether any files that were previously OK have become "due" for a newline fix. If so, Git should error out, explaining that the developer should also commit fixed newlines at the same time. Or if the developer insists that they want to break everything, use --force. MOTIVATION I recently tried to submit a few pull requests to someone else's repository that had this problem. First I went through the infuriating experience of figuring out why git was being so weird (I'm not a _complete_ git noob but this was totally new to me). Then I found myself unable to actually make any contributions. I imagine it's OK if you're the owner, but pull requests require merges from time to time, and I was almost always prevented from merging things. On top of this, I had to convince the repo owner that his repo required a change (a 200 kLOC change!). I wasn't even sure I was right to begin with. In fact I still wonder if I got it totally wrong and you guys are going to tell me how dumb I am being. Paul -- 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