Todd Zullinger <t...@pobox.com> writes: > 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.
