And not even just visual garbage, but it also seems that git diff it’s piking those differences in lines endings as real differences between files. Since Git is a Unix developed app, if you have files with Widows line-endings and things haven’t been configured properly, you end up with a bunch of files with something like this: The reality is, in Unix they decided to have just one character, so they could save some space in memory -which has all the sense in the world in the old days- and that’s it.
#GITHUB DESKTOP LINE ENDINGS WINDOWS#
Some people argue that Windows way is more correct, because it uses a new line and carriage return, while Unix it’s just new line, which could be just that, new line but not the carriage return to the left most part of the line and in consequence you’d end at the end of a new line, instead of the beginning. While Windows uses for line endings the CR/LF, convention that is also know as ASCII 0x0d or \r and a newline \n which ASCII is 0x0a, Unix-like system uses just LF, also called \n or in ASCII 0x0a. Line endings are handled in a different way on Unix-like systems -like Linux or macOS- and on Windows systems. In spite of that, and as if dealing with the changes to merge weren’t enough, line endings on the subversion version -sorry for the redundancy- of the repo were showing when I performed a git diff of the two branches. To bring those changes back to the original repo, I had to set it up as a non related branch of the original repo, as I explain here, so I can proceed and merge it later. After that, the fork was set as a Subversion repo and store in a local server.
I had a repo that suffered an unconventional fork, in other works, someone decided copy it and work outside Git -or any other version control system.
0 kommentar(er)
