I have come across a strange problem in GIT. Recently our codebase has moved to GIT from SVN. So, when I have cloned the repository on my local and I am doi
execute below command
cd repo<Project>
git config --global core.autocrlf true
This is expected behavior of GitLab and there is nothing wrong in this case. See the issue( https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52936). We may skip those white space changes from compression using GitLab UI. Steps to hide/ignore white space changes.
After doing this you the compare section will show only real changes. Below is the screenshot which you refer.
This sounds like a problem with CRLF vs LF line endings to me.
I believe that SVN and GIT both store text files in their repositories with LF line endings, and that both convert between LF and CRLF line endings when checking files in and out of the repository from the working copy.
Unfortunately SVN and GIT have different ways of deciding which files are text files, so they don't always agree on whether line ending conversion is required.
GIT is pretty good at guessing but allows control using attributes - run "git help attributes" to get an explanation.
SVN uses svn properties on individual files, and these properties either have to be set manually or else via configured auto-props rules.
I'm guessing that the files were originally committed to SVN on Windows, that you're running GIT on Windows, and that you created the GIT repository using "git svn".
If so then my best guess is that your SVN repository didn't have svn properties set, so SVN stored files with CRLF line endings in the SVN repository without conversion. If you then imported the SVN repository into a new GIT repository with "git svn" then the GIT repository will also contain CRLF line endings. This is not the expected format for text files in the GIT repository, so it can cause problems. In particular, I think "git diff" compares what is already in the repository (with CRLF line endings) with what would be committed to the repository (with LF line endings) and finds that every line is different.
One way to understand what's going on would be to clone the repository to a Linux machine with core.autocrlf = false (or not set). In this case there wouldn't be any CRLF line ending conversion to confuse the matter, and you could see what the line endings in the checked out files are. My guess is that they'll have CRLF line endings because of CRLF line endings stored in the GIT repository.
If my hypothesis is correct then I think you have 2 options:
(1) Fix the GIT repo to contain LF rather than CRLF line endings. On Windows (with core.autocrlf=true) I think you could do this by touching every file (without making any changes), then commit all files that GIT reports as changed. On Linux (with core.autocrlf=false) I think you could do it by running dos2unix on all of the text files and then committing them.
(2) Treat all files as binary rather than text so that GIT doesn't attempt line ending conversion at all. I think you could do this by committing a .gitattributes file containing "* -text" (without the quotes). The disadvantage of this is that you'll get CRLF line endings when checking out on Linux.