On 2024-07-07 01:26:13 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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.
