Re: tests fail on windows with default git settings

Hi

On Sun, 7 Jul 2024 at 07:07, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2024-07-07 01:26:13 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > Do we want to support checking out with core.autocrlf?
> >
> > -1. It would be a constant source of breakage, and you could never
> > expect that (for example) making a tarball from such a checkout
> > would match anyone else's results.
>
> WFM.
>
>
> > > If we do not want to support that, ISTM we ought to raise an error
> somewhere?
> >
> > +1, if we can figure out how.
>
> I can see two paths:
>
> 1) we prevent eol conversion, by using the right magic incantation in
> .gitattributes
>
> 2) we check that some canary file is correctly encoded, e.g. during meson
> configure (should suffice, this is realistically only a windows issue)
>
>
> It seems that the only realistic way to achieve 1) is to remove the "text"
> attribute from all files. That had me worried for a bit, thinking that
> might
> have a larger blast radius. However, it looks like this is solely used for
> line-ending conversion. The man page says:
> "This attribute marks the path as a text file, which enables end-of-line
> conversion:"
>
>
> Which sounds like it'd work well - except that it appears to behave oddly
> when
> updating to such a change in an existing repo -
>
> cd /tmp/;
> rm -rf pg-eol;
> git -c core.eol=crlf -c core.autocrlf=true clone ~/src/postgresql pg-eol;
> cd pg-eol;
> git config core.eol crlf; git config core.autocrlf true;
> stat src/test/modules/test_json_parser/tiny.json -> 6748 bytes
>
> cd ~/src/postgresql
> stat src/test/modules/test_json_parser/tiny.json -> 6604 bytes
> echo '* -text' >> .gitattributes
> git commit -a -m tmp
>
> cd /tmp/pg-eol
> git pull
> git st
> ...
> nothing to commit, working tree clean
> stat src/test/modules/test_json_parser/tiny.json -> 6748 bytes
>
> I.e. the repo still is in CRLF state.
>
> But if I reclone at that point, the line endings are in a sane state.
>
>
> IIUC this is because line-ending conversion is done only during
> checkout/checkin.
>
>
> There are ways to get git to redo the normalization, but it's somewhat
> awkward [1].
>

Yeah, I vaguely remember playing with core.autocrlf many years ago and
running into similar issues.

>
> OTOH, given that the tests already fail, I assume our windows contributors
> already have disabled autocrlf?
>

I can't speak for others of course, but at least as far as building of
installers is concerned, we use tarballs not git checkouts.

For my own work; well, I've started playing with PG17 on Windows just in
the last month or so and have noticed a number of test failures as well as
a weird meson issue that only shows up on a Github actions runner. I was
hoping to look into those issues this week as I've been somewhat
sidetracked with other work of late.

--
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
EDB: https://www.enterprisedb.com