Description
Dear Lorenz,
I've been looking at why precommit is failing the tests with the new UCRT toolchain. It is not related to UCRT, but to git configuration (cc'ing Stefan as a maintainer of git2r).
The output is
── Failure (test-hook-roxygenize.R:7:3): roxygen runs are done if necessary ────
extract_diff_root(".") not equal to add_trailing_linebreak(text2).
2/2 mismatches
x[1]: "x <- function()\r\n"
y[1]: "x <- function()\n"
x[2]: " NULL\r\n"
y[2]: " NULL\n"
The tests are creating files in a local git repository, using writeLines(), so the files end up with Windows line endings, CRLF:
text2 <- c("x <- function()", " NULL")
writeLines(text2, "R/third.R")
git2r::add(".", "R/third.R")
The test then expects that git diff contents will have the Unix line endings, LF:
expect_equal(extract_diff_root("."), add_trailing_linebreak(text2))
but, with the default git (per git source code, which is the default in Msys2/Rtools git), the line endings will be those CRLF that the file has and the test will fail.
This is configured by git option core.autocrlf, which is by default false (no conversion). I assume that your tests assume that core.autocrlf is set to true, which is the default offered by Git4Windows, and when that Git is installed and I suppose on PATH, git2r will automatically use its configuration.
With msys2 git, one may change the settings by
git config --global core.autocrlf true
which will produce ~/.gitconfig file with that setting, and the tests will pass, because the CRLF will be converted to LF by git2r. One can check with git2r::git_config_files() to see which config file is used.
Could you please fix your tests/package to work regardless of which is the default setting on the system? If it is just a question of the test, perhaps you could set this per the test repository, or compare the results in a way that does not differentiate between different line endings.
However, overall I think it would be worth at least documenting or improving the behavior also at git2r level. In R, it is customary to have line endings as LF only (reading text files converts CRLF to LF, writing converts LF to CRLF). So, R users may be quite surprised by getting CRLF in strings from git2r, such as in the precommit tests, and it might break their code, as it did. Maybe by default git2r should better always return LF line endings to R, and possibly that won't affect much existing users, as most probably use auto.crlf set to true anyway. That's why I cc'd Stefan and I'd leave the details to you, but please fix your package so that it works also with the default git settings of core.autocrlf, and hence it passes CRAN package checks also with the UCRT toolchain.
Thanks
[R core developer]