On Wed, Nov 27, 2013 at 11:25 AM, Dave Abrahams
Beman Dawes
writes: After doing a lot of reading of git docs and about how others dealt with similar problems, that was also my conclusion. I'm wondering why others haven't suggested renormalization?
They have.
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?
It depends on whether you want to "correct" history or not. If you want to go back in time and renormalize, then all the SHAs in submodules change, and the branches in the master repo need to be rewritten accordingly.
My initial reaction is not to "correct" history. I'm quite comfortable with the idea that files from svn were moved into "git" as is, and then as part of bringing Boost into the git world, we renormalized. I think of it this way; a programmer deeply familiar with git who has never seen Boost before should not be surprised necessarily, beyond having to grasp the idea that Boost is a set of individual libraries rather than on giant library. IIUC, such a programmer would expect normalized line endings in master and develop heads, and .attributes files to ensure portability. --Beman