Set GIT_WORK_TREE rather than core.worktree

[canton7]

Is your feature request related to a problem? Please describe.

I hit an issue entirely of my own making. I use yadm from an MSYS2 shell, and I switched from using the built-in git to using git for windows, in order to get a significant speed boost.

However, having done so, any yadm commands resulted in lots of errors being printed to stderr:

fatal: Invalid path '/c': No such file or directory

After much digging, it turns out that these were being printed by git, because core.worktree in .local/share/yadm/repo.git was set to a unix-style path (/c/Users/Me) rather than one which git for windows was expecting (c:/Users/Me).

Now, yadm knows about this, and it properly handles this sort of path conversion (which I was very impressed to find). So had I done a yadm clone using git for windows, I'm sure that everything would be fine: yadm would have set core.worktree to a correctly-formatted path. However, it's the fact that I switched git installation after the creation of .local/share/yadm/repo.git which caused everything to break.

Describe the solution you'd like

Using the env var GIT_WORK_TREE rather than setting core.worktree should avoid this issue. Simply doing a search/replace to turn YADM_WORK into GIT_WORK_TREE (and removing core.worktree) almost works (there's a spurious cygpath: can't convert empty path).

Thanks!

[TheLocehiliosan]

I think I understand this strange case you had.

However, the repo's local configuration is the only source for the configured work tree. This is set during yadm clone or yadm init (adjustable with the -w parameter). Once those operations are done, the repo config is queried every time.

It would be possible to set GIT_WORK_TREE if yadm forced the work tree to be $HOME, but that must stay configurable.

[canton7]

I see, I hadn't twigged that was configurable. That makes sense, thanks!