I see. I gonna implement the suggestion I proposed last week

Thank you!

Out of curiosity, could you share the content of the file having conflict ?

setup.cfg is changed: all line endings were switched from LF to CR/LF.

That is helpful. Do you have some global git settings ? If yes, what is the value of core.autocrlf ?

Here is what we have on the windows dashboard:

dashboard@overload MINGW64 ~
$ pwd
/c/Users/dashboard

dashboard@overload MINGW64 ~
$ git config --list
core.symlinks=false
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
diff.astextplain.textconv=astextplain
rebase.autosquash=true
credential.helper=manager

I suspect that the value is not set to true on your build machine.

See https://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git#2825829

Yes, the issue is most likely caused by EOL style difference between git and setup tools, but you cannot require developers to use any particular git setting.

Even just touching timestamps is undesirable (as they trigger rebuilding of some code parts), but modifying EOL is a major change of file content. The build system just should not mess with revision-controlled source directories in any way.

Could you confirm that you deleted the directories python-setuptools* after this commit:
https://github.com/Slicer/Slicer/commit/306c573937ea05c38eb3544f464413bf4b3020d2#diff-b46bf7cc031a1ce22413460b166dac69

If not, I suggest you deleted them and reconfigure.

The build system just should not mess with revision-controlled source directories in any way

For files that have to be LF independently of the platform, the approach is to setup gitattribute. For example, see [1]

Generally speaking, for all the other text files, git is checking them out with the line ending matching the platform. As outline in the enclosed screenshot, git is indeed doing the right thing on the windows dashboard. setup.cfg as CRLF as expected. And when python is updating that file, it is also using the line ending of the platform. [2]

The issue is that I can not reproduce the problem. It seems specific to this build machine where the global setting are most likely improperly set.

If for some reason, core.autocrlf is not set to true on this machine, I suggest to set it.
See https://help.github.com/articles/dealing-with-line-endings/#platform-windows

[1] https://github.com/Slicer/Slicer/commit/ed787ec2054a76d0607d15f4710c8f42d459b797#diff-f42f0d2a3b4eae234bb2fe9a3d44bfb7

[2] The default is to use text mode, which may convert '\n' characters to a platform-specific representation on writing and back on reading.
See
https://docs.python.org/2/glossary.html#term-universal-newlines
https://stackoverflow.com/questions/10785131/line-endings-in-python#10785225

setup-cfg-diff.png (36,516 bytes)

setup-cfg-overload.png (117,824 bytes)

If for some reason, core.autocrlf is not set to true on this machine, I suggest to set it.

We cannot require users to set personal preferences in certain way. Enabling core.autocrlf caused various problems for me in the past, so I would not like to enable it again.

If gitattributes fixes it then it's great! I do a clean build and report back.

Enabling core.autocrlf caused various problems for me in the past

This is most likely the default now on windows. I don't remember changing anything on this windows machine. If I recall, I accepted the recommendation when installing it bash.

And it is the recommended approach when working on cross platform project: https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#__code_core_autocrlf_code

If gitattributes fixes it then it's great!

I am curious to see if removing the python-setuptools* directories and reconfiguring address the problem.

Enabling core.autocrlf caused various problems for me in the past,

If autocrlf is indeed set to false, this means that all files checkout from git will have LF and not CRLF.

I can confirm that gitignore fixed the problem: build does not fail anymore due to the changed file on the latest trunk version.

Thank you @jcfr!