Re: [BUG] completion.commands does not remove multiple commands

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 2, 2019, 01:18 UTC
Message-ID: <xmqqef7q6pm1.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190301221551.GD31362@zaya.teonanacatl.net>

Todd Zullinger <tmz@pobox.com> writes:

Show 10 quoted lines

> Hmm.  The comments in list_cmds_by_config() made me wonder
> if not using a local repo config was intentional:
>
>         /*
>          * There's no actual repository setup at this point (and even
>          * if there is, we don't really care; only global config
>          * matters). If we accidentally set up a repository, it's ok
>          * too since the caller (git --list-cmds=) should exit shortly
>          * anyway.
>          */

Doesn't the output from list-cmds-by-config get cached at the completion script layer in $__git_blah variables, and the cached values are not cleared when you chdir around? If you allowed the repo-specific configuration to affect its output, the cached values need to be reset when you cross repository boundaries. Otherwise you'd see complaints like "I have this in repo A but not in repo B; when I start from repo A, it gets completed even after I go to repo B. If I start from repo B, I do not get completion in either of them" (the former is because repo-A specific result gets cached, the latter is because the cache is populated with the result taken in repo-B that doesn't have customization and stays around even when you visit repo-B).

I think it is a sensible design decision to forbid per-repo config to relieve us from having to worry about when to invalidate the cache and all associated complexities.