Confirm the issue, same output occurred building Chromium Embedded branch 3112 (currently corresponding to chromium refs/tags/60.0.3112.10).

Note that depot_tools explicitly sets `git config --system core.autocrlf false` during Windows Git installation [1], which suggests that this should be the required/documented/expected value.

[1] https://cs.chromium.org/chromium/tools/depot_tools/bootstrap/win/git_bootstrap.py?rcl=76c6ea28e5f9437f9653c204eb63f9ec14cd7484&l=149

I have already another git installation with core.autocrlf set to true. It can be a conflict in the scenario depot_tools' git set crlf to false, but then reads it using another git invocation which happens to be the existing installation and this one returns true?

I don't know how much sense that makes, but I was performing the checkout (not the build) using the documented automate-git.py script of Chromium Embedded - which invokes depot_tools - and I ended up with core.crlf on true despite depot_tools git setting it to false.

@comment#3: `git config --system` and `git config --global` write to different locations on Windows. Using the Git installed with depot_tools the `--system` flag will write to "C:\Users\[User]\.gitconfig" and the `--global` flag will write to "depot_tools\git-2.10.0-64_bin\mingw64\etc\gitconfig". The priority read order lowest-to-highest is system, global, repository-specific. So, it would be quite easy to override or loose the system value set during depot_tools installation if you use or install a different version of Git.

Can you please confirm how can I sync the codebase correctly on my system? With limited internet services its hard to delete the sync because of just core.autocrlf messup.

Thanks.

As this issue is specific to Internals>Network>DomainSecurityPolicy , difficult to traige from TE end.

 Issue 732746  has been merged into this issue.

I'd like to hear from the infra team about whether it's okay to require the checkout to have correct `clrf` settings.

As an intermediate compromise, we could consider modifying the error to point out this issue on Windows. (We could even do so conditionally, based on a small sanity check for line endings.)

Agree that a clearer error or solution would help. My build mysteriously broke today and it seems it's related to this.

FYI anyone suffering a similar problem can use dos2unix on the two affected files (transport_security_state_static.pins and transport_security_state_static_unittest.pins) 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/89d553d1c6f6d386c52fc3ade38eb4fe2508ab7f

commit 89d553d1c6f6d386c52fc3ade38eb4fe2508ab7f
Author: martijn <martijn@martijnc.be>
Date: Sun Jul 09 21:44:30 2017

Add a .gitattributes file to force LF line-endings in .pins files.

This change forces the pins files to use LF line-endings and adds a check to
detect CRLF line-endings that outputs a more helpful error message.

BUG= 729553 

Review-Url: https://codereview.chromium.org/2941543002
Cr-Commit-Position: refs/heads/master@{#485165}

[modify] https://crrev.com/89d553d1c6f6d386c52fc3ade38eb4fe2508ab7f/.gitattributes
[modify] https://crrev.com/89d553d1c6f6d386c52fc3ade38eb4fe2508ab7f/net/tools/transport_security_state_generator/input_file_parsers.cc

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This was kind of fixed by enforcing LF endings in the pin file in .gitattributes. So it doesn't matter anymore whether the program chokes on CRLF or not.