# Zsh completion: cached __git_repo_path affects shell session, breaks completion

1 messages from 2024-04-24 to 2024-04-24. Participants: D. Ben Knoble.
Thread: https://gitlist.dev/t/61357

## D. Ben Knoble, 2024-04-24 13:46

Subject: Zsh completion: cached __git_repo_path affects shell session, breaks completion
Message-ID: <CALnO6CBv3+e2WL6n6Mh7ZZHCX2Ni8GpvM4a-bQYxNqjmgZdwdg@mail.gmail.com>
URL: https://gitlist.dev/e/CALnO6CBv3%2Be2WL6n6Mh7ZZHCX2Ni8GpvM4a-bQYxNqjmgZdwdg%40mail.gmail.com

```
I can only reproduce this in Zsh, not with Bash (using equivalent
commands), though the caching behavior comes from Bash (fad9484f0a
(completion: cache the path to the repository, 2017-02-03)).

For example (with Zsh):

mkdir a b b/c
for d (a b); git -C $d init && git -C $d commit --allow-empty -m init
cd a
git branch foo
pushd ../b/c
git branch bar
git rebase <TAB>… # completion for bar available; C-c to abort
declare -p __git_repo_path # outputs /path/to/b/.git
popd
git branch # outputs foo, main
git rebase <TAB>… # completion candidates are bar, main!

I've only been able to observe this with rebase so far (e.g., using
switch instead doesn't seem to trigger the problem).

I wonder if all callers of __git_find_repo_path should declare `local
__git_repo_path`? That might defeat some caching, but I don't think
__git_repo_path should be set globally in a shell session, and the
script is explicitly intended to be sourced… again, though, I think
Bash does the correct thing and somehow Zsh is capturing this variable
that it shouldn't be.

-- 
D. Ben Knoble

```