use user_path_prep() in git_vaccinated()

[dpprdan]

git_sitrep() errors when trying to check .gitignore.

library(usethis)
git_sitrep()
#> Git config (global)
#> * Name: 'Daniel Possenriede'
#> * Email: 'possenriede@gmail.com'
#> * Global (user-level) gitignore file: '~/.gitignore'
#> Warning in file(con, "r"): cannot open file 'C:/Users/Daniel/
#> Documents/.gitignore': No such file or directory
#> Error in file(con, "r"): cannot open the connection

Apparently this is caused by the call to git_vaccinated()

usethis:::git_vaccinated()
#> Warning in file(con, "r"): cannot open file 'C:/Users/Daniel/
#> Documents/.gitignore': No such file or directory
#> Error in file(con, "r"): cannot open the connection

The root of the problem seems to be a difference in the path expansion of ~ in git and R.

The core.excludesFile is configured like so (run in Git-Bash)

$ git config --global core.excludesFile
~/.gitignore
$ realpath ~/.gitignore
/c/Users/Daniel/.gitignore

This is also picked up by usethis

(path <- usethis:::git_ignore_path("user"))
#> [1] "~/.gitignore"

but this is then passed to read_utf8() |> base::readLines(), and that expands path to

path.expand(path)
#> [1] "C:/Users/Daniel/Documents/.gitignore"

I think we have to user_path_prep() the path first. (Note that I, as a user, supplied the core.excludesFile path, so user_path_prep()ing it is only consistent with

usethis/principles.md

Line 80 in 865e929

In order to be consistent everywhere, all paths supplied by the user should be processed with `user_path_prep()`.

That way we can also eliminate the full-path hack workaround in ensure_core_excludesFile() (which prevents .gitconfig from being portable).

usethis/R/utils-git.R

Lines 84 to 87 in 865e929

	if (!is_windows()) {
	# express path relative to user's home directory, except on Windows
	path <- path("~", path_rel(path, path_home()))
	}

Session info

sessioninfo::session_info()
#> - Session info ---------------------------------------------------------------
#>  setting  value
#>  version  R version 4.1.2 (2021-11-01)
#>  os       Windows 10 x64 (build 19043)
#>  system   x86_64, mingw32
#>  ui       RTerm
#>  language en
#>  collate  German_Germany.1252
#>  ctype    German_Germany.1252
#>  tz       Europe/Berlin
#>  date     2022-01-05
#>  pandoc   2.16.2 @ C:/PROGRA~1/Pandoc/ (via rmarkdown)
#> 
#> - Packages -------------------------------------------------------------------
#>  package     * version date (UTC) lib source
#>  askpass       1.1     2019-01-13 [1] CRAN (R 4.1.0)
#>  backports     1.4.1   2021-12-13 [1] CRAN (R 4.1.2)
#>  cli           3.1.0   2021-10-27 [1] CRAN (R 4.1.1)
#>  crayon        1.4.2   2021-10-29 [1] CRAN (R 4.1.1)
#>  credentials   1.3.2   2021-11-29 [1] CRAN (R 4.1.2)
#>  digest        0.6.29  2021-12-01 [1] CRAN (R 4.1.2)
#>  ellipsis      0.3.2   2021-04-29 [1] CRAN (R 4.1.0)
#>  evaluate      0.14    2019-05-28 [1] CRAN (R 4.1.0)
#>  fansi         0.5.0   2021-05-25 [1] CRAN (R 4.1.0)
#>  fastmap       1.1.0   2021-01-25 [1] CRAN (R 4.1.0)
#>  fs            1.5.2   2021-12-08 [1] CRAN (R 4.1.2)
#>  gert          1.5.0   2022-01-03 [1] CRAN (R 4.1.2)
#>  glue          1.6.0   2021-12-17 [1] CRAN (R 4.1.2)
#>  highr         0.9     2021-04-16 [1] CRAN (R 4.1.0)
#>  htmltools     0.5.2   2021-08-25 [1] CRAN (R 4.1.1)
#>  knitr         1.37    2021-12-16 [1] CRAN (R 4.1.2)
#>  lifecycle     1.0.1   2021-09-24 [1] CRAN (R 4.1.1)
#>  magrittr      2.0.1   2020-11-17 [1] CRAN (R 4.1.0)
#>  openssl       1.4.6   2021-12-19 [1] CRAN (R 4.1.2)
#>  pillar        1.6.4   2021-10-18 [1] CRAN (R 4.1.1)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.1.0)
#>  purrr         0.3.4   2020-04-17 [1] CRAN (R 4.1.0)
#>  R.cache       0.15.0  2021-04-30 [1] CRAN (R 4.1.0)
#>  R.methodsS3   1.8.1   2020-08-26 [1] CRAN (R 4.1.0)
#>  R.oo          1.24.0  2020-08-26 [1] CRAN (R 4.1.0)
#>  R.utils       2.11.0  2021-09-26 [1] CRAN (R 4.1.1)
#>  reprex        2.0.1   2021-08-05 [1] CRAN (R 4.1.0)
#>  rlang         0.4.12  2021-10-18 [1] CRAN (R 4.1.1)
#>  rmarkdown     2.11    2021-09-14 [1] CRAN (R 4.1.1)
#>  rprojroot     2.0.2   2020-11-15 [1] CRAN (R 4.1.0)
#>  rstudioapi    0.13    2020-11-12 [1] CRAN (R 4.1.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.1.2)
#>  stringi       1.7.6   2021-11-29 [1] CRAN (R 4.1.2)
#>  stringr       1.4.0   2019-02-10 [1] CRAN (R 4.1.0)
#>  styler        1.6.2   2021-09-23 [1] CRAN (R 4.1.1)
#>  sys           3.4     2020-07-23 [1] CRAN (R 4.1.0)
#>  tibble        3.1.6   2021-11-07 [1] CRAN (R 4.1.2)
#>  usethis     * 2.1.5   2021-12-09 [1] CRAN (R 4.1.2)
#>  utf8          1.2.2   2021-07-24 [1] CRAN (R 4.1.0)
#>  vctrs         0.3.8   2021-04-29 [1] CRAN (R 4.1.0)
#>  withr         2.4.3   2021-11-30 [1] CRAN (R 4.1.2)
#>  xfun          0.29    2021-12-14 [1] CRAN (R 4.1.2)
#>  yaml          2.2.1   2020-02-01 [1] CRAN (R 4.1.0)
#> 
#>  [1] C:/Users/Daniel.AK-HAMBURG/Documents/R/win-library/4.1
#>  [2] C:/Program Files/R/R-4.1.2/library
#> 
#> ------------------------------------------------------------------------------

[jennybc]

I've looked over this and there's something that doesn't quite sit right about it. The path aspects of usethis are a real hotspot for introducing undesired change. So I'll have to let this sit until I think about it harder (I'm not working on usethis atm.)

[jennybc]

Recording research I did previously on global gitignore on Windows (i.e. I can see that I've visited these links before):

https://stackoverflow.com/questions/7335420/global-git-ignore

Summary: I think, with modern Git Windows tooling, this is often how core.excludesFile is going to appear in global (user-level) .gitconfig:

git config --global core.excludesFile '~/.gitignore'

If so, that ~/ should be expanded in the *nix / fs / bash way, not the R way.

[jennybc]

OK I uploaded this into my head again. Yes I think we should process this path with user_path_prep() before handing it over to base R for reading.

I still think usethis should write this path as an absolute path on Windows. Based on my reading, that still seems to be safest at this point. At least, it's unambiguous.