`repo_path` differs when invoked via `git alias` (`git wt ...`) in bare-layout repositories

[yasuhiroki]

Description

When using a bare repository layout, repo_path may resolve differently depending on whether wt is invoked directly or via a Git alias.

This seems related to Git injecting environment variables such as GIT_DIR when executing shell aliases (alias = "!cmd"). This variables influence the behavior of internal git commands used by worktrunk.

Context

Repository layout (bare layout)

repo/
  .git/   # bare repository
  main/   # worktree

Configure a simple alias in worktrunk for reproduction:

[aliases]
echo = "echo {{repo_path}}"

Also configure a Git alias:

git config --global alias.wt '!wt'

Result:

$ cd /path/to/repo

$ wt step echo
◎ Running alias echo
/path/to/repo/.git

$ git wt step echo
◎ Running alias echo
/path/to/repo # → not `/path/to/repo/.git`

Additional observations

Debug logs show the following when the issue occurs:

$ git rev-parse --is-bare-repository [.git]
[wt-trace] context=.git cmd="git rev-parse --is-bare-repository"
fatal: not a git repository: '.git'

This appears to happen when GIT_DIR is present in the environment.

For example:

cd repo/.git

git rev-parse --is-bare-repository
# → true

GIT_DIR=.git git rev-parse --is-bare-repository
# → fatal: not a git repository: '.git'

This suggests that when GIT_DIR is set to .git, Git resolves it relative to the current directory (repo/.git/.git), causing the failure.

Since Git sets GIT_DIR when running shell aliases (git <alias>), this may explain why git wt ... behaves differently from invoking wt directly.

Versions

• wt: 0.34.1
• git: 2.50.1 (Apple Git-155)

[worktrunk-bot]

Thanks for the very clear report — your diagnosis was spot on. When git runs a shell alias, it exports GIT_DIR (sometimes as a relative path like .git), and worktrunk's internal git commands run with different current_dir values, which caused the relative path to re-resolve against the wrong directory.

I've opened #1915 with a fix that resolves inherited relative GIT_* path variables to absolute paths at startup, so the git alias context is preserved without breaking discovery. A maintainer will review it shortly.