Re: [PATCH v2 1/2] .gitattributes: ensure t/oid-info/* has eol=lf
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Dec 14, 2018, 11:10 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1812141204040.43@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20181214005101.GT890086@genre.crustytoothpaste.net>
Hi Brian,
On Fri, 14 Dec 2018, brian m. carlson wrote:
Show 14 quoted lines
> 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