On 2017-10-18 15:08, Paul Vinkenoog wrote:
Mark Rotteveel wrote:

Fixed in https://github.com/mrotteveel/test-firebird-documentation-4

I cloned this repository and built a number of targets, both in master
and in the B_Release branch.
Everything worked exactly as in my CVS checkout.

A number of source files in my (Windows) CVS working dir have Unix
line endings though, whereas their Git counterparts have DOS endings.

Yes, those are the four files I mentioned earlier. I have normalized those files, so they will not get line-ending conversion issues in future updates.

Git always uses LF for internal storage of text files, only on checkout / commit will it apply line-ending conversion to what is either configured in the client, or - in this case - by the .gitattributes file.

That's no problem, as long as it doesn't lead to a huge number of
'changes' and log messages when such a file is committed, cluttering
the history and drowning the real changes.

That shouldn't happen. I have double checked this by using `git read-tree --empty` after adding the .gitattributes, any issues with white space normalization between what is currently stored and what git would do when updating a file and applying the correct line-ending normalization should show up that way.

Anyway, I guess that won't occur if we commit all our work to CVS
before the conversion/transition, get a fresh git clone afterwards and
work only from that. Am I right?

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).

And yes, it would be best to get a fresh clone after migration. Although performing a git clone and moving any files that were still under modification should not be a problem.


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