Hi On Sun, 7 Jul 2024 at 07:07, Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2024-07-07 01:26:13 -0400, Tom Lane wrote: > > Andres Freund <and...@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. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com
