Re: [Firebird-docs] Test repository CVS to git migration

[Mark R. <ma...@la...>]

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.

Mark