Re: [PATCH] completion: zsh: support completion after "git -C <path>"

On Mon, Aug 17, 2026 at 3:29 PM Lutz Lengemann <[email protected]> wrote:
>
> Hi Ben
>
> (Resending, my earlier reply was rejected by the list for being HTML.)
>
> On Wed, Jul 15, 2026, at 00:34, D. Ben Knoble wrote:
> > Any progress here? I just found my local copy of this patch and was
> > briefly surprised to see it hadn't graduated anywhere (until I
> > realized conversation had stalled at this point).
>
> Sorry for the very late reply, I was on holiday and then other life
> things got in the way of answering :(  I do have a v2 ready, which I
> have just pushed to my fork, and which follows this message.

No worries! Hope you enjoyed. (I didn't see v2 come in anywhere, but
I'll keep my eye out.)

> Junio C Hamano <[email protected]> writes:
>
> > Doesn't it want to do something similar to what __git_main in
> > git-completion.bash does at the beginning, namely, this part?
>
> It does, thanks.  v2 no longer skips only leading -C options, but walks
> the words in front of the command and skips over the global options and,
> where they take one, their arguments, like __git_main does.
>
> That also makes "git -p checkout <TAB>" and "git --git-dir=<path>
> checkout <TAB>" complete the arguments of the command, which they did
> not before.

Nice side-effect :)

> Two related gaps are left alone, as they are bugs in the _arguments
> specification rather than in the command lookup: -c is not listed there
> at all,

[no comment]

> and --git-dir and friends are spelled "--git-dir=-", which
> accepts only "--git-dir=<path>", not the "--git-dir <path>" form.  I can
> send patches for those separately.

We were discussing this recently in some threads about Bash
completion, and I think we landed on "gitcli(1) really prefers the
stuck form, and so do completion helpers, so let's stick with that for
now" ?

>
> "D. Ben Knoble" <[email protected]> writes:
>
> > But we mark these local, so how do they propagate to the other
> > functions?
>
> zsh scoping is dynamic, not lexical, so a variable declared "local" in
> __git_zsh_main is visible in the functions that are called from it, the
> bash helpers included.  That is how __git_dir and __git_cmd_idx are
> handed down already, and __git_C_args works the same way.

Thanks. I must have known that, but it's remarkably difficult to find
spelled out in the manual. The closest I can find is the "LOCAL
PARAMETERS" section of zshparam(1), which could really use an example
to demonstrate that local is still dynamic.

> > We should probably note in the log message that the _directories
> > completion will not account for previous -C
>
> I added a note about this in the log message.

Great

> > I think we could do _slightly_ better by using a state "->dir" or
> > something, accumulating the current prefix, and passing that to
> > _directories as a prefix with -W
>
> I tried that and it works, but it changes what -C offers, which is more
> than fixing the completion after -C, so I left it out; happy to send it
> on top.  Two things to watch out for there: the accumulated path has to
> be made absolute, as -W with ".." gave me the directories of "/", and
> the accumulation has to stop before the word that is being completed.

A follow-up is fine with me if you decide to send it (and if not,
that's fine, too).

> > By the way, I've realized that "git -<tab>" has the same problem (a
> > giant list of files after the other option completions)
>
> That one is older than this patch: the file listing comes from the
> fallback at the end of _git,
>
>         let _ret && _default && _ret=0
>
> which is where the "use-compctl" and "globbed-files" tags in your
> _complete_help dump come from.

Thanks for explaining!

> I could not reproduce the repeated
> description block with "zsh -f" and only the _complete completer, so
> something in my setup or yours may differ there.  Either way it wants
> its own topic.

Yes, I agree that can be its own topic. I've been re-studying the
completion system again recently, so maybe I'll be better equipped to
debug my setup later… I do play with the tag-order style for Git
completions, so I wonder if that's interfering.

Thanks!

-- 
D. Ben Knoble