I have the following set-up for my Git repositories:
- "Central" bare repository
- 2 cloned repositorys
- file "test.txt" in the repository
The file looks like this:
Line 1 Line 2 Line 3 Line 4 Line 5
It has no newline (\n, \n\r, \r) at the end. The last character is "5".
Now I modify the file in my first cloned repository like this:
Line 1 Line 2 Line 3 Line 4 Line 5 Line 6
I commit this change and push it to my central repository. Again this file has no newline at the end.
In my second repository I do not pull. But I change the file like this:
Line 1 Line 2 Line 4 Line 5
Line 3 was deleted. This file has no newline at the end either. Now I commit this change. Afterwards I pull with --rebase
and the file in the rebased commit looks this way:
Line 1 Line 2 Line 4 Line 5Line6
I know that a text file should end with a newline by standard. But is there a way to avoid this behavior?
My system set-up is this:
- OS: Windows 10
- Git: 2.11.0.windows.1
- Git-UI: Git Extensions 2.49
- KDiff3: 0.9.97 (32-bit)
Research done:
- The behavior does not occur when there is a newline at the end of the file.
- If a changed file contains a newline there is a conflict shown at least. But the automatic merge is not good.
Reasons for doing this:
I am migrating from CVS and would like to keep a straight forward commit history by now. This is why I would like to use rebasing. But the migrated repository contains some text files without newlines at the end of the files. A workaround would be to add newlines in all text files in the repository. But I would like to avoid massive changes.