Re: [BUG?] Weird interaction between `git -C`, aliases and worktrees

[Elijah Newren <newren@gmail.com>]

On Wed, Oct 14, 2020 at 8:27 AM Philippe Blain
<levraiphilippeblain@gmail.com> wrote:
>
> Hello all,
>
> Up to recently I had an alias 'st' for `git status`, i.e. `git config alias.st status`.
> This works well in the main working tree as well as secondary worktrees (`git worktree add ...`),
> and also shows paths relative to the current directory if I'm not at the root of the repo,
> just like `git status`.
>
> Now I wanted to change my alias so that it ran `git status` and then an additional command, i.e.
> `git config alias.st '!git status && date'` (for demonstration purposes).
> This works correctly in the main worktree and secondary worktrees, but since aliases
> run from the root of the repo, the paths in the output of 'git st' are not relative
> to the current directory.
>
> So my next attempt was `git config alias.st '!git -C "${GIT_PREFIX}" status && date'`,
> so that paths would be relative in the output. However, this works in the main worktree
> but fails badly in the secondary worktree:
>
> ```
> rm -rf test &&
> rm -rf test2 &&
> git init test &&
> cd test &&
> mkdir folder &&
> date>>folder/file &&
> git add folder/file &&
> git ci -m "commit" &&
> git config alias.st '!git -C "${GIT_PREFIX}" status && date' &&
> date >>folder/file &&
> echo '=== `git st` in main worktree at root ===' &&
> git st &&
> cd folder &&
> echo '=== `git st` in main worktree in folder ===' &&
> git st &&
> git worktree add ../test2 &&
> cd ../test2 &&
> date >>folder/file &&
> echo '=== `git st` in secondary worktree at root ===' &&
> git st &&
> cd folder &&
> echo '=== `git st` in secondary worktree in folder ===' &&
> git st
> ```
>
> The last commands ouputs:
>
> ```
> === `git st` in secondary worktree in folder ===
> On branch test2
> Changes not staged for commit:
>   (use "git add/rm <file>..." to update what will be committed)
>   (use "git restore <file>..." to discard changes in working directory)
>         deleted:    folder/file
>
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
>         file
>
> no changes added to commit (use "git add" and/or "git commit -a")
> ```
>
> So something is wrong in the automatic worktree path detection...
> If I replace the alias with
>
>     git config alias.st '!git -C "${GIT_PREFIX}" --work-tree=$PWD status && date'
>
> then it works correctly, but I have a feeling this should not be necessary...
>
> I've CC-ed Eric (because of his work on `git worktree`) and Elijah (because
> I remember he worked on `dir.c` so maybe this is related to that code, but I'm
> not sure).
>
> Cheers,
> Philippe

I don't think there's anything dir.c-specific here (thank
goodness...).  I extended your aliases slightly to echo the command
they would run (so I could see the value of $GIT_PREFIX) as well as to
print all the GIT_* environment variables, and found that GIT_DIR was
set as well as GIT_PREFIX, so you can duplicate the funny results with

GIT_DIR=$WHEREVER git -C folder status

or even

git --git-dir=$WHEREVER -C folder status

In fact, you don't need any special worktrees setup; using these
commands will trigger the funny status output.  Looking at the
documentation for core.worktree, I see

"If --git-dir or GIT_DIR is specified but none of --work-tree,
GIT_WORK_TREE and core.worktree is specified, the current working
directory is regarded as the top level of your working tree."

and indeed, I find that if I run from the toplevel:

git --work-tree=folder/ status

then I see the same output that you are complaining about.  So, it
seems that "the current working directory is regarded as the top level
of your working tree" is implemented to take effect AFTER the "-C
folder" first changes the current working directory.

I haven't tracked down where in the code this happens, but I suspect
that this is what is happening and is the culprit behind the behavior
you are seeing.  If I am right, it doesn't answer whether this is a
bug, of course -- it could be that this ordering is intentional and
desired, or it could be that this ordering is not wanted.  Anyway,
does this help you track it down?