
On 27 November 2013 14:25, Beman Dawes
Since we can't fix these files in historical versions we could re-run the conversion with gitattributes that unsets the text attribute for the problematic files (something like "*.bat -text", "*.vsproj -text", "*.svg -text"). Then in git update the gitattributes (to something like "*.bat text eol=crlf", "*.vsproj text eol=crlf", "*.svg text") and normalize the files so that it does what we want. We can script that, so it shouldn't require too much work.
As long as we are sure the .gitattributes are correct, and then renormalize, why do we have to rerun the conversion at all? What am I missing?
If someone checks out an older version of a module (i.e. before normalization) then they'll still have this problem. If the conversion is rerun with gitattributes set as I described then I don't think they will. It won't fix the files, it'll just tell git not to expect them to have the correct newlines. But this isn't a big deal, and there are possibly issues with this approach, so it might not be worth it.