Re: [PATCH v2 1/2] .gitattributes: ensure t/oid-info/* has eol=lf

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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