On Thu, May 16, 2019 at 7:15 PM Eric Sunshine <sunsh...@sunshineco.com> wrote: > > On Thu, May 16, 2019 at 7:42 AM Duy Nguyen <pclo...@gmail.com> wrote: > > On Thu, May 16, 2019 at 6:33 PM Eric Sunshine <sunsh...@sunshineco.com> > > wrote: > > > You run afoul of it in other situations, as well. For instance, say > > > you have your index file in a non-standard location: > > > > > > $ export GIT_INDEX_FILE=../storage/index > > > $ git worktree add --detach other > > > Preparing worktree (detached HEAD c9156d2) > > > fatal: Unable to create '/.../foo/other/../storage/index.lock': No > > > such file or directory > > > $ > > > > > Oh if it's relative $GIT_INDEX_FILE then I think its our environment.c > > code that does not work so well when we chdir() away. I vaguely recall > > something about this when discussing Jeff's chdir-notify series. But > > it turns out that's about chdir() in run-command.c [1]. But the idea > > is still the same, all variables are supposed to be relative to $CWD. > > Whenever you move $CWD you should reparent all of them, including > > $GIT_INDEX_FILE. > > builtin/worktree.c:add_worktree() is already assigning > new-worktree-specific values for GIT_DIR and GIT_WORK_TREE, so for the > specific example I showed above, the correct fix would be for > add_worktree() to remove GIT_INDEX_FILE from the environment before > invoking other Git commands, correct?
I'll work on the assumption that all $GIT_* are for the _current_ worktree, not the one we're creating. If so, yes we need to sanitize $GIT_*, maybe do it the same way submodules do (I think prepare_submodule_repo_env() is the right one). -- Duy
