Request: refuse to commit .gitattributes unless the change also commits correct line endings

[Paul Salmon <paul.b.salmon@gmail.com>]

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