Respect env variables when running gix

[cruessler]

While working on gix blame I found that, for testing purposes, I wanted to run env GIT_WORK_TREE=… gix blame which did not work as expected. This PR changes that. I don’t know whether it was intentional not to take env variables into account. If it was, feel free to just close this PR!

[Byron]

Thanks a lot, it's appreciated!

It doesn't seem to be working though and I think I know why. In theory, it should already be working anyway, but… let me try to make this work, I will push on top (without force).

[Byron]

This was surprisingly tricky 😅.

In short, here is what happened.

• core.worktree can be used to set the worktree, but it's meant to be put into a git configuration file, and relative paths are relative to that (so .. would be the normal worktree, ../../ would be one above), which is unintuitive when provided via gix -c core.worktree=.., which seems to do nothing.
  • git -c core.worktree is completely ignored
• GIT_WORK_TREE wasn't wired in the env-init sequence, which allows it to become accessible through git configuration. try GIT_WORK_TREE=.. gix config to see what I mean - now that it's fixed it shows up.
• The cleanest solution was to check where the now wired core.worktree value is coming from so it can either be relative to the git dir or to the current dir.
• lastly, there was a Rust issue due to &dyn FnMut which made me go back to using impl for the filter.

Now it should work though, and I think it's intuitive as well despite the quite different functioning of repository discovery (compared to Git). That should be fine, as both Git and gitoxide still find the same repository/worktree, but gix now can also do -c core.worktree overrides.

[cruessler]

Fascinating! This looked like such an innocuous change! :-)