Hi Brian, On Fri, 14 Dec 2018, brian m. carlson wrote: > On Wed, Dec 12, 2018 at 10:14:53AM -0800, Derrick Stolee via GitGitGadget wrote: > > > > diff --git a/.gitattributes b/.gitattributes > > index acf853e029..3738cea7eb 100644 > > --- a/.gitattributes > > +++ b/.gitattributes > > @@ -13,3 +13,4 @@ > > /Documentation/gitk.txt conflict-marker-size=32 > > /Documentation/user-manual.txt conflict-marker-size=32 > > /t/t????-*.sh conflict-marker-size=32 > > +/t/oid-info/* eol=lf > > Yeah, this seems like a sensible thing to do. I assumed the shell on > Windows would read data as text files, not as binary files. This is a tricky thing right there. The Bash we use is borrowed from the MSYS2 project, which tries to stay as close to Unix/Linux as possible, i.e. it does *not* treat Carriage Return as part of the line ending. Changing that default would break tons of things, I would expect. > It's kinda hard for me as a non-Windows user to predict what will need > CRLF endings and what will need LF endings with Git on Windows. Right. It is my hope that I get the Azure Pipelines support going soon, so that Pull Requests on GitHub are tested on Windows, too. Hopefully that would help. Typically, I monitor the Windows builds of `pu` closely. But in this case, it did not catch because the current Azure Pipeline that runs these tests (triggered via Travis) specifically forces `core.autocrlf` to `false`, as that definition pre-dates the work I've done to make Git's source code CR/LF safe. I do have a build definition to test with `core.autocrlf = true`, but that only runs on Git for Windows' `master`, and once git.git has its own Azure Pipeline, I plan on adding another phase to test that directly. Ciao, Dscho
