I know what you are getting at, but I think it cuts both ways.
I can well imagine that the build structure where "make && make install"
will go to old-files and new-files directories and install the contents
overlayed in the same destination, and .gitattributes may be being used as
a way to "fix" some aspect of "oldness" in old-files/ files until the
sources are fixed. So an equally valid work sequence might be:
git mv old-files/some-file.html new-files/
edit new-files/some-file.html
git add new-files/some-file.html
git commit
in which case adding a new "some-file.html crlf" entry to .gitattributes
in new-files/ directory would be just _wrong_.
So I am not opposed to a mechanism to _let_ users makes a copy of an entry
that covers (or used to cover) one path to apply to another path that was
not covered by it, but doing it unconditionally would not be such a good
idea.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html