Bazel: git_repository rule: Inconsistency in handling of line endings

[Xjs]

Description of the problem / feature request:

If a git repository is imported into the workspace with git_repository on Windows, in most cases git's core.autocrlf option is active, modifying the line endings of text files in the imported repository. This can lead to differences in build artefacts when building on Windows vs. Unixes, even if the workspace itself is exactly identical (due to the mangling of the imported repo).

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I have created and documented a working minimal test case on https://github.com/Xjs/bazel-java-test/blob/master/case3.md that illustrates the behaviour.

I have previously worked on the git_repository rule and am willing to propose a way to set the core.autocrlf option consistently. I can start working on this next week if desired.

What operating system are you running Bazel on?

These test cases were produced on Windows 10 and Ubuntu 18.04.

What's the output of bazel info release?

Tested with release 0.25.2

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

[email protected]:Xjs/bazel-java-test.git
70202cc99f788de3fd89c48be169bb09946a86e8
70202cc99f788de3fd89c48be169bb09946a86e8

[laurentlb]

cc @aehlig, @laszlocsomor, what do you think?

[laszlocsomor]

@Xjs , thank you for the details in the repro repo!

I confirm your leads: with core.autocrlf=true I indeed get CRLF endings on manual git clone, and I can also repro the bug with Bazel.

Passing --config core.autocrlf=input to git clone fixes the issue for me. I think git_repository should do the same.

[laszlocsomor]

Passing --config core.autocrlf=input to git clone fixes the issue for me. I think git_repository should do the same.

@aehlig : WDYT?

[baskus]

I hit this issue too. I found a workaround until the issue is fixed though. Simply add

build --action_env=GIT_CONFIG_NOSYSTEM=1

to your .bazelrc and git shouldn't pick up the system config anymore. This resolved the issue I hit where my local system had one value for core.autocrlf and the build machine had another.