Thanks for confirming the issue is related to core.autocrlf on Windows. To avoid this issue, I think we should use (or emulate) the -w option of git diff to ignore any whitespace change when considering line changes (which are most of the time not taking any role in issues).
It would also be more consistent with the blame.
I set the respective config option in the .gitattributes file in the repo itself. Maybe the Git plugin does not read this file or the settings on the host have priority?
# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto
It is maybe a limitation of JGit, but we will dig more into it when tackling the ticket I created. In the meantime you’ll have to configure your CI boxes to not alter line ends when checking out the code.
I don’t think this ticket is related (it talk about the archive command that works remotely). But still I found several other tickets talking about limited support for some attributes in .gitattributes. Again we will dig into it when talking the ticket I created.
I’ve been trying a few different things, and as mentioned in my previous comment I was able to make it work when setting core.autocrlf=false. In this case I made a new commit with the setting set to false, and then ran the SonarQube scan.
I have also had success with the setting set to true, odly enough. I haven’t investigated in detail why this is, since I do have a working setup now. What I think is worth pointing out is, that even when I was experiencing the problem originally, I did have core.autocrlf=true in C:/ProgramData/Git/config, as you can see in my previous posts. When I set git config --global core.autocrlf true, it adds the setting to %HOMEDRIVE%/.gitconfig. So it would seem that the Git plugin doesn’t get the setting from C:/ProgramData/Git/config but does get the setting from %HOMEDRIVE%/.gitconfig.
Thanks a lot for the hint i got it finally working too:
Before changing anything git config --get core.autocrlf printed true
I tried git config --global core.autocrlf false as suggested (goes into ~/.gitconfig) → diff still for the whole file
After git config --global core.autocrlf true → correct diffs
So i can confirm that SonarQube/JGit reads the ~/.gitconfig only and it seems that it has a different default config value for core.autocrlf than the native Git.
Thanks for the feedback. To me it kind of make sense JGit doesn’t consider C:/ProgramData/Git/config since it is an “implementation specific location”. Out of curiosity, how did you ended up having a setting there? Is it a feature specific to the Windows Git client?
I installed Git for Windows via the installer, and there is a window where it asks you what you want for the setting. So I imagine the Git for Windows installer sets the setting in that directory.
When I try and run the command git config --global core.autocrlf true on our Windows box it just complains that git is not a recognised command.
'git' is not recognized as an internal or external command,
operable program or batch file.
Do I need to install git for Windows on this box just to be able to set this property?
We use Azure Devops with our own agents. When running the analysis in verbose mode it tells me it might be looking in the agent folder at the gitattributes file, however running the above command in these folders has made no difference…
@Andreas_Petersen No, unfortunately that didn’t work. When I look at the agents git config file (I was looking at gitattributes before). I can see the following
[core]
symlinks = false
autocrlf = true
So that suggests it is in there… Maybe I have a slightly different issue to others in that I’m using self hosted build agents for Azure Devops. @Julien_HENRY do you have any ideas on where this setting could be that I need to update?
Thanks! I have updated the extension plugin as suggested and now is the version 1.9.0.1725, but I still have the issue reported by all the users. Nothing is changed with this update.
To confirm the problem is related to autocrlf, does it work if you set autocrlf to true, either at project level or global (for example git config --global core.autocrlf true)?
I tested globally and locally the git command before to execute the build on the self-hosted Azure DevOps agent (that is not on the same server machine of SonarQube server)