On 2017-10-18 16:45, Norman Dunbar wrote:
On 18/10/17 15:15, Mark Rotteveel wrote:

Given the normalization done during conversion, that should not be a problem (unless a new file extension is introduced that isn't considered a text file by the configuration of the conversion).

The thing I mentioned with autocrlf is the old way of doing things, up
to Git 1.6 I think. From then on, .gitattributes is the way to go.

Old way, but still the way if a repository has no .gitattributes (like for example the Firebird core repository).

However, if a new file type appears, Git will determine whether it is
a text file by checking to see if it fails the tests for binary files.

Git's text file detection is pretty good, but I'm specifically talking about the line-ending normalization that I'm doing during the repository conversion process. I have decided to use a cautious approach, which means I'll only do line-ending normalization on files that are positively text files (based on a large list 'borrowed' from Subversion, with some project specific alterations, see https://www.lawinegevaar.nl/firebird/cvs_migration.html for details).

All other files will be left untouched on the off chance they are binary, as the conversion process uses git fast-import to load the data, git will not apply its own line-ending normalization at that time (in essence, git fast-import handles everything as if it is binary).

So if a new file extension for a text file would be introduced between now and the final conversion, then I would specifically need to take that into account, or we'll get a white space correction on the first commit that touches that file after migration.

But odds are probably negligible that a new (and unknown) file extension will be introduced to the project before migration.


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-docs mailing list

Reply via email to