{"thread":{"id":"65823","subject":"[PATCH] completion: zsh: support completion after \"git -C <path>\"","startedAt":"2026-06-17T15:30:59Z","lastAt":"2026-08-26T22:04:46Z","messageCount":15,"participants":["Lutz Lengemann via GitGitGadget","Ben Knoble","Junio C Hamano","D. Ben Knoble","Lutz Lengemann"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"545768","messageId":"pull.2155.git.1781710256081.gitgitgadget@gmail.com","threadId":"65823","inReplyTo":null,"subject":"[PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"Lutz Lengemann via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-06-17T15:30:55Z","receivedAt":"2026-06-17T15:30:59Z","isPatch":true,"body":"From: Lutz Lengemann <lutz@lengemann.net>\n\nThe zsh completion wrapper (__git_zsh_main) did not handle the global -C\noption, so \"git -C <path> <command> <TAB>\" offered nothing and could not\ncomplete a command's arguments.\n\nThree things are needed to make it work, all scoped to -C:\n\n  - Add -C to the _arguments specification, so completion no longer stops\n    at it.\n\n  - Advance __git_cmd_idx past any leading \"-C <path>\" options. The index\n    is hard-coded to 1, i.e. the command is assumed to be the first\n    argument; with -C present the command sits two words later for each\n    -C, so the bash helpers otherwise look at the wrong word and produce\n    nothing.\n\n  - Collect the -C paths into __git_C_args, as __git_main does. The bash\n    helpers run git to resolve aliases and list refs; without the -C\n    paths they run in the current directory, so completion fails whenever\n    the cwd is not the target repository or the command is an alias.\n\nWith these, \"git -C <path> <command> <TAB>\" completes the command, its\noptions and its arguments, including outside the repository, through\naliases, and with repeated -C options.\n\nSigned-off-by: Lutz Lengemann <lutz@lengemann.net>\n---\n    completion: zsh: support completion after \"git -C \"\n    \n    This patch is intentionally scoped to -C, but the underlying problem is\n    more general. The zsh wrapper hard-codes __git_cmd_idx=1, i.e. it\n    assumes the command is always the first argument. That assumption breaks\n    argument completion after any global option that precedes the command,\n    not just -C — e.g. --git-dir, --work-tree, --namespace, -c, and\n    -p/--paginate. After those, git <opt> <command> <TAB> currently\n    completes the command name but not its arguments.\n    \n    The same approach generalizes cleanly: instead of skipping only leading\n    -C options, walk all leading global options and their arguments to\n    locate the command and its true index (mirroring the option scan in\n    __git_main in git-completion.bash), while collecting -C into\n    __git_C_args and --git-dir into __git_dir as today.\n    \n    I kept this revision narrow for reviewability and because git -C is the\n    case where I miss the completion, but I'm happy to extend it to cover\n    the other global options in a follow-up (or fold it into this patch) if\n    that's preferred.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2155%2Fmobilutz%2Fzsh-complete-global-C-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2155/mobilutz/zsh-complete-global-C-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/2155\n\n contrib/completion/git-completion.zsh | 9 +++++++++\n 1 file changed, 9 insertions(+)\n\ndiff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh\nindex c32186a977..323049be8b 100644\n--- a/contrib/completion/git-completion.zsh\n+++ b/contrib/completion/git-completion.zsh\n@@ -227,6 +227,7 @@ __git_zsh_main ()\n \t\t'(-p --paginate --no-pager)'{-p,--paginate}'[pipe all output into ''less'']' \\\n \t\t'(-p --paginate)--no-pager[do not pipe git output into a pager]' \\\n \t\t'--git-dir=-[set the path to the repository]: :_directories' \\\n+\t\t'*-C[run as if git was started in <path>]: :_directories' \\\n \t\t'--bare[treat the repository as a bare repository]' \\\n \t\t'(- :)--version[prints the git suite version]' \\\n \t\t'--exec-path=-[path to where your core git programs are installed]:: :_directories' \\\n@@ -252,6 +253,14 @@ __git_zsh_main ()\n \t\t;;\n \t(arg)\n \t\tlocal command=\"${words[1]}\" __git_dir __git_cmd_idx=1\n+\t\tlocal -a __git_C_args\n+\t\tlocal -i i=2\n+\n+\t\twhile [[ ${orig_words[i]} == -C ]]; do\n+\t\t\t__git_C_args+=(-C ${orig_words[i+1]})\n+\t\t\t(( __git_cmd_idx += 2 ))\n+\t\t\t(( i += 2 ))\n+\t\tdone\n \n \t\tif (( $+opt_args[--bare] )); then\n \t\t\t__git_dir='.'\n\nbase-commit: 0fae78c9d55efe705877ea537fe42c59164ccd94\n-- \ngitgitgadget\n"},{"id":"545781","messageId":"BD572902-D8E9-497A-9B90-E6889675145D@gmail.com","threadId":"65823","inReplyTo":"pull.2155.git.1781710256081.gitgitgadget@gmail.com","subject":"Re: [PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-06-17T17:17:16Z","receivedAt":"2026-06-17T17:17:28Z","isPatch":true,"body":"I’d like to take a deeper look at this, but I’m not sure when I can.\n\n> Le 17 juin 2026 à 11:37, Lutz Lengemann via GitGitGadget <gitgitgadget@gmail.com> a écrit :\n> \n> From: Lutz Lengemann <lutz@lengemann.net>\n> \n> The zsh completion wrapper (__git_zsh_main) did not handle the global -C\n> option, so \"git -C <path> <command> <TAB>\" offered nothing and could not\n> complete a command's arguments.\n\nOne easy note, though: our commit style prefers describing the code base before the patch in question in the present tense (« does not handle », « offers nothing »).\n\nThe below imperative mood looks appropriate to me.\n\n> \n> Three things are needed to make it work, all scoped to -C:\n> \n>  - Add -C to the _arguments specification, so completion no longer stops\n>    at it.\n> \n>  - Advance __git_cmd_idx past any leading \"-C <path>\" options. The index\n>    is hard-coded to 1, i.e. the command is assumed to be the first\n>    argument; with -C present the command sits two words later for each\n>    -C, so the bash helpers otherwise look at the wrong word and produce\n>    nothing.\n> \n>  - Collect the -C paths into __git_C_args, as __git_main does. The bash\n>    helpers run git to resolve aliases and list refs; without the -C\n>    paths they run in the current directory, so completion fails whenever\n>    the cwd is not the target repository or the command is an alias.\n> \n> With these, \"git -C <path> <command> <TAB>\" completes the command, its\n> options and its arguments, including outside the repository, through\n> aliases, and with repeated -C options.\n> \n> Signed-off-by: Lutz Lengemann <lutz@lengemann.net>\n> ---\n>    completion: zsh: support completion after \"git -C \"\n> \n>    This patch is intentionally scoped to -C, but the underlying problem is\n>    more general. The zsh wrapper hard-codes __git_cmd_idx=1, i.e. it\n>    assumes the command is always the first argument. That assumption breaks\n>    argument completion after any global option that precedes the command,\n>    not just -C — e.g. --git-dir, --work-tree, --namespace, -c, and\n>    -p/--paginate. After those, git <opt> <command> <TAB> currently\n>    completes the command name but not its arguments.\n> \n>    The same approach generalizes cleanly: instead of skipping only leading\n>    -C options, walk all leading global options and their arguments to\n>    locate the command and its true index (mirroring the option scan in\n>    __git_main in git-completion.bash), while collecting -C into\n>    __git_C_args and --git-dir into __git_dir as today.\n> \n>    I kept this revision narrow for reviewability and because git -C is the\n>    case where I miss the completion, but I'm happy to extend it to cover\n>    the other global options in a follow-up (or fold it into this patch) if\n>    that's preferred.\n> \n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2155%2Fmobilutz%2Fzsh-complete-global-C-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2155/mobilutz/zsh-complete-global-C-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/2155\n> \n> contrib/completion/git-completion.zsh | 9 +++++++++\n> 1 file changed, 9 insertions(+)\n> \n> diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh\n> index c32186a977..323049be8b 100644\n> --- a/contrib/completion/git-completion.zsh\n> +++ b/contrib/completion/git-completion.zsh\n> @@ -227,6 +227,7 @@ __git_zsh_main ()\n>        '(-p --paginate --no-pager)'{-p,--paginate}'[pipe all output into ''less'']' \\\n>        '(-p --paginate)--no-pager[do not pipe git output into a pager]' \\\n>        '--git-dir=-[set the path to the repository]: :_directories' \\\n> +        '*-C[run as if git was started in <path>]: :_directories' \\\n>        '--bare[treat the repository as a bare repository]' \\\n>        '(- :)--version[prints the git suite version]' \\\n>        '--exec-path=-[path to where your core git programs are installed]:: :_directories' \\\n> @@ -252,6 +253,14 @@ __git_zsh_main ()\n>        ;;\n>    (arg)\n>        local command=\"${words[1]}\" __git_dir __git_cmd_idx=1\n> +        local -a __git_C_args\n> +        local -i i=2\n> +\n> +        while [[ ${orig_words[i]} == -C ]]; do\n> +            __git_C_args+=(-C ${orig_words[i+1]})\n> +            (( __git_cmd_idx += 2 ))\n> +            (( i += 2 ))\n> +        done\n> \n>        if (( $+opt_args[--bare] )); then\n>            __git_dir='.'\n> \n> base-commit: 0fae78c9d55efe705877ea537fe42c59164ccd94\n> --\n> gitgitgadget\n> \n"},{"id":"545782","messageId":"xmqqa4stw09d.fsf@gitster.g","threadId":"65823","inReplyTo":"pull.2155.git.1781710256081.gitgitgadget@gmail.com","subject":"Re: [PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-06-17T17:21:50Z","receivedAt":"2026-06-17T17:21:54Z","isPatch":true,"body":"\"Lutz Lengemann via GitGitGadget\" <gitgitgadget@gmail.com> writes:\n\n> From: Lutz Lengemann <lutz@lengemann.net>\n>\n> The zsh completion wrapper (__git_zsh_main) did not handle the global -C\n> option, so \"git -C <path> <command> <TAB>\" offered nothing and could not\n> complete a command's arguments.\n\nI do not write, use, or customize zsh, so please take my comments\nwith huge grains of salt, or just ignore them completely (your\nchoice) ;-), but one thng I noticed was that ...\n\n> diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh\n> index c32186a977..323049be8b 100644\n> --- a/contrib/completion/git-completion.zsh\n> +++ b/contrib/completion/git-completion.zsh\n> @@ -227,6 +227,7 @@ __git_zsh_main ()\n>  \t\t'(-p --paginate --no-pager)'{-p,--paginate}'[pipe all output into ''less'']' \\\n>  \t\t'(-p --paginate)--no-pager[do not pipe git output into a pager]' \\\n>  \t\t'--git-dir=-[set the path to the repository]: :_directories' \\\n> +\t\t'*-C[run as if git was started in <path>]: :_directories' \\\n>  \t\t'--bare[treat the repository as a bare repository]' \\\n>  \t\t'(- :)--version[prints the git suite version]' \\\n>  \t\t'--exec-path=-[path to where your core git programs are installed]:: :_directories' \\\n\n... this part talks about not just \"-C<dir>\" but knows about\nall the other options that the \"git\" potty itself takes, while ...\n\n> @@ -252,6 +253,14 @@ __git_zsh_main ()\n>  \t\t;;\n>  \t(arg)\n>  \t\tlocal command=\"${words[1]}\" __git_dir __git_cmd_idx=1\n> +\t\tlocal -a __git_C_args\n> +\t\tlocal -i i=2\n> +\n> +\t\twhile [[ ${orig_words[i]} == -C ]]; do\n> +\t\t\t__git_C_args+=(-C ${orig_words[i+1]})\n> +\t\t\t(( __git_cmd_idx += 2 ))\n> +\t\t\t(( i += 2 ))\n> +\t\tdone\n\n... this only knows about \"-C<dir>\" and nothing else.\n\nDoesn't it want to do something similar to what __git_main in\ngit-completion.bash does at the beginning, namely, this part?\n\n__git_main ()\n{\n\tlocal i c=1 command __git_dir __git_repo_path\n\tlocal __git_C_args C_args_count=0\n\tlocal __git_cmd_idx\n\n\twhile [ $c -lt $cword ]; do\n\t\ti=\"${words[c]}\"\n\t\tcase \"$i\" in\n\t\t--git-dir=*)\n\t\t\t__git_dir=\"${i#--git-dir=}\"\n\t\t\t;;\n\t\t--git-dir)\n\t\t\t((c++))\n\t\t\t__git_dir=\"${words[c]}\"\n\t\t\t;;\n\t\t--bare)\n\t\t\t__git_dir=\".\"\n\t\t\t;;\n\t\t--help)\n\t\t\tcommand=\"help\"\n\t\t\tbreak\n\t\t\t;;\n\t\t-c|--work-tree|--namespace)\n\t\t\t((c++))\n\t\t\t;;\n\t\t-C)\n\t\t\t__git_C_args[C_args_count++]=-C\n\t\t\t((c++))\n\t\t\t__git_C_args[C_args_count++]=\"${words[c]}\"\n\t\t\t;;\n\t\t-*)\n\t\t\t;;\n\t\t*)\n\t\t\tcommand=\"$i\"\n\t\t\t__git_cmd_idx=\"$c\"\n\t\t\tbreak\n\t\t\t;;\n\t\tesac\n\t\t((c++))\n\tdone\n"},{"id":"545872","messageId":"CALnO6CD9P4+e=YPdKaLfSBOk-H3_ir64pBP-qMKNNvzUNqunXQ@mail.gmail.com","threadId":"65823","inReplyTo":"pull.2155.git.1781710256081.gitgitgadget@gmail.com","subject":"Re: [PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-06-18T17:43:24Z","receivedAt":"2026-06-18T17:43:36Z","isPatch":true,"body":"[apologies in advance for the strange format below]\n\nOn Wed, Jun 17, 2026 at 11:37 AM Lutz Lengemann via GitGitGadget\n<gitgitgadget@gmail.com> wrote:\n>\n> From: Lutz Lengemann <lutz@lengemann.net>\n>\n> The zsh completion wrapper (__git_zsh_main) did not handle the global -C\n> option, so \"git -C <path> <command> <TAB>\" offered nothing and could not\n> complete a command's arguments.\n>\n> Three things are needed to make it work, all scoped to -C:\n>\n>   - Add -C to the _arguments specification, so completion no longer stops\n>     at it.\n>\n>   - Advance __git_cmd_idx past any leading \"-C <path>\" options. The index\n>     is hard-coded to 1, i.e. the command is assumed to be the first\n>     argument; with -C present the command sits two words later for each\n>     -C, so the bash helpers otherwise look at the wrong word and produce\n>     nothing.\n>\n>   - Collect the -C paths into __git_C_args, as __git_main does. The bash\n>     helpers run git to resolve aliases and list refs; without the -C\n>     paths they run in the current directory, so completion fails whenever\n>     the cwd is not the target repository or the command is an alias.\n>\n> With these, \"git -C <path> <command> <TAB>\" completes the command, its\n> options and its arguments, including outside the repository, through\n> aliases, and with repeated -C options.\n>\n> Signed-off-by: Lutz Lengemann <lutz@lengemann.net>\n> ---\n>     completion: zsh: support completion after \"git -C \"\n>\n>     This patch is intentionally scoped to -C, but the underlying problem is\n>     more general. The zsh wrapper hard-codes __git_cmd_idx=1, i.e. it\n>     assumes the command is always the first argument. That assumption breaks\n>     argument completion after any global option that precedes the command,\n>     not just -C — e.g. --git-dir, --work-tree, --namespace, -c, and\n>     -p/--paginate. After those, git <opt> <command> <TAB> currently\n>     completes the command name but not its arguments.\n>\n>     The same approach generalizes cleanly: instead of skipping only leading\n>     -C options, walk all leading global options and their arguments to\n>     locate the command and its true index (mirroring the option scan in\n>     __git_main in git-completion.bash), while collecting -C into\n>     __git_C_args and --git-dir into __git_dir as today.\n>\n>     I kept this revision narrow for reviewability and because git -C is the\n>     case where I miss the completion, but I'm happy to extend it to cover\n>     the other global options in a follow-up (or fold it into this patch) if\n>     that's preferred.\n\nSee Junio's review for whether we should expand in this patch or a follow-up.\n\nIn reply to Junio:\n\n> [the new handling only knows about -C]\n> Doesn't it want to do something similar to what __git_main in\n> git-completion.bash does at the beginning, namely, this part?\n\nYeah, we probably do want to skip over -c, etc. (I see some support for\n--bare and --git-dir, but not skipping over it.) Still, this patch makes\nthings no worse in that regard, and improves the situation for -C\nAFAICT.\n\nIn reply to Lutz:\n\n> +        local -a __git_C_args\n> +        local -i i=2\n> +\n> +        while [[ ${orig_words[i]} == -C ]]; do\n> +            __git_C_args+=(-C ${orig_words[i+1]})\n> +            (( __git_cmd_idx += 2 ))\n> +            (( i += 2 ))\n> +        done\n\nI don't see either of these 2 local variables used anywhere else…\n\n…well, except the Bash completion helpers, I suppose. But we mark these\nlocal, so how do they propagate to the other functions?\n\nStill, I was able to try this out with the somewhat hacky\n\n    zsh # new shell :)\n    # absolute path important\n    autoload -Uz $PWD/contrib/completion/git-completion.zsh\n    compdef git-completion.zsh git\n\n    git -C <tab>\n\nand it does prioritize directories there (though I still get a listing\nof files afterwards, so the screen is taken up by that gigantic listing\nin git.git, for example).\n\nBy the way, I've realized that \"git -<tab>\" has the same problem (a\ngiant list of files after the other option completions), and worse has\nsome _funky_ output!\n\n    git -<tab> # without patch\n    (option)\n    --bare\n    --exec-path\n    --git-dir\n    --help\n    --html-path\n    --info-path\n    --man-path\n    --namespace\n    --no-pager\n    --no-replace-objects\n    --paginate\n    --version\n    --work-tree\n\n    -p\n\n    # treat the repository as a bare repository\n    # path to where your core git programs are installed\n    # set the path to the repository\n    # prints the synopsis and a list of the most commonly used commands\n    # print the path where gits HTML documentation is installed\n    # print the path where the Info files are installed\n    # print the manpath (see `man(1)`) for the man pages\n    # set the git namespace\n    # do not pipe git output into a pager\n    # do not use replacement refs to replace git objects\n    # pipe all output into less\n    # prints the git suite version\n    # set the path to the working tree\n    [ed: the above block repeats twice more before the (file) listing below]\n    (file)\n    […]\n\nHere's the output of _complete_help (^Xh by default) in both situations,\nin case that helps to understand either the extra files listing (1) in\nthe example further back or the issue with single letter options (2)\njust mentioned:\n\n1: tags in context :completion::complete:git::\n    option-C-1     (_arguments __git_zsh_main _git git-completion.zsh)\n    use-compctl    (_default _git git-completion.zsh)\n    globbed-files  (_files _default _git git-completion.zsh)\ntags in context :completion::complete:git:option-C-1:\n    directories    (_directories _arguments __git_zsh_main _git\ngit-completion.zsh)\n    globbed-files  (_files _directories _arguments __git_zsh_main _git\ngit-completion.zsh)\n    all-files      (_files _directories _arguments __git_zsh_main _git\ngit-completion.zsh)\n\n2: tags in context :completion::complete:git::\n    argument-1 options  (_arguments __git_zsh_main _git)\n    use-compctl         (_default _git)\n    globbed-files       (_files _default _git)\ntags in context :completion::complete:git:argument-1:\n    common-commands alias-commands all-commands  (__git_zsh_main _git)\n    common-commands                              (__git_zsh_cmd_common\n__git_zsh_main _git)\n    alias-commands                               (__git_zsh_cmd_alias\n__git_zsh_main _git)\n    all-commands                                 (__git_zsh_cmd_all\n__git_zsh_main _git)\ntags in context :completion::complete:git:options:\n    options  (_arguments __git_zsh_main _git)\n\n> +        '*-C[run as if git was started in <path>]: :_directories' \\\n\nWe should probably note in the log message that the _directories\ncompletion will not account for previous -C; that is, after typing\n\n    git -C dir -C <tab>\n\nwe will complete directories in \".\", not \"dir\". That's probably a\nreasonable limitation for now, but I think we could do _slightly_ better\nby using a state \"->dir\" or something, accumulating the current prefix,\nand passing that to _directories as a prefix with -W (see _path_files in\nzshcompsys, which _directories delegates to via _files, IIUC).\n\n-- \nD. Ben Knoble\n"},{"id":"548171","messageId":"CALnO6CB1vJ7RtBzTUSJSfYtfH+W2MZCFEkqNWeBXbWJ2r3Pdyg@mail.gmail.com","threadId":"65823","inReplyTo":"CALnO6CD9P4+e=YPdKaLfSBOk-H3_ir64pBP-qMKNNvzUNqunXQ@mail.gmail.com","subject":"Re: [PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-07-14T22:34:59Z","receivedAt":"2026-07-14T22:35:11Z","isPatch":true,"body":"Hi Lutz,\n\nOn Thu, Jun 18, 2026 at 1:43 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:\n>\n> [apologies in advance for the strange format below]\n>\n> On Wed, Jun 17, 2026 at 11:37 AM Lutz Lengemann via GitGitGadget\n> <gitgitgadget@gmail.com> wrote:\n> >\n> > From: Lutz Lengemann <lutz@lengemann.net>\n> >\n> > The zsh completion wrapper (__git_zsh_main) did not handle the global -C\n> > option, so \"git -C <path> <command> <TAB>\" offered nothing and could not\n> > complete a command's arguments.\n> >\n> > Three things are needed to make it work, all scoped to -C:\n> >\n> >   - Add -C to the _arguments specification, so completion no longer stops\n> >     at it.\n> >\n> >   - Advance __git_cmd_idx past any leading \"-C <path>\" options. The index\n> >     is hard-coded to 1, i.e. the command is assumed to be the first\n> >     argument; with -C present the command sits two words later for each\n> >     -C, so the bash helpers otherwise look at the wrong word and produce\n> >     nothing.\n> >\n> >   - Collect the -C paths into __git_C_args, as __git_main does. The bash\n> >     helpers run git to resolve aliases and list refs; without the -C\n> >     paths they run in the current directory, so completion fails whenever\n> >     the cwd is not the target repository or the command is an alias.\n> >\n> > With these, \"git -C <path> <command> <TAB>\" completes the command, its\n> > options and its arguments, including outside the repository, through\n> > aliases, and with repeated -C options.\n> >\n> > Signed-off-by: Lutz Lengemann <lutz@lengemann.net>\n> > ---\n> >     completion: zsh: support completion after \"git -C \"\n> >\n> >     This patch is intentionally scoped to -C, but the underlying problem is\n> >     more general. The zsh wrapper hard-codes __git_cmd_idx=1, i.e. it\n> >     assumes the command is always the first argument. That assumption breaks\n> >     argument completion after any global option that precedes the command,\n> >     not just -C — e.g. --git-dir, --work-tree, --namespace, -c, and\n> >     -p/--paginate. After those, git <opt> <command> <TAB> currently\n> >     completes the command name but not its arguments.\n> >\n> >     The same approach generalizes cleanly: instead of skipping only leading\n> >     -C options, walk all leading global options and their arguments to\n> >     locate the command and its true index (mirroring the option scan in\n> >     __git_main in git-completion.bash), while collecting -C into\n> >     __git_C_args and --git-dir into __git_dir as today.\n> >\n> >     I kept this revision narrow for reviewability and because git -C is the\n> >     case where I miss the completion, but I'm happy to extend it to cover\n> >     the other global options in a follow-up (or fold it into this patch) if\n> >     that's preferred.\n>\n> See Junio's review for whether we should expand in this patch or a follow-up.\n>\n> In reply to Junio:\n>\n> > [the new handling only knows about -C]\n> > Doesn't it want to do something similar to what __git_main in\n> > git-completion.bash does at the beginning, namely, this part?\n>\n> Yeah, we probably do want to skip over -c, etc. (I see some support for\n> --bare and --git-dir, but not skipping over it.) Still, this patch makes\n> things no worse in that regard, and improves the situation for -C\n> AFAICT.\n>\n> In reply to Lutz:\n>\n> > +        local -a __git_C_args\n> > +        local -i i=2\n> > +\n> > +        while [[ ${orig_words[i]} == -C ]]; do\n> > +            __git_C_args+=(-C ${orig_words[i+1]})\n> > +            (( __git_cmd_idx += 2 ))\n> > +            (( i += 2 ))\n> > +        done\n>\n> I don't see either of these 2 local variables used anywhere else…\n>\n> …well, except the Bash completion helpers, I suppose. But we mark these\n> local, so how do they propagate to the other functions?\n>\n> Still, I was able to try this out with the somewhat hacky\n>\n>     zsh # new shell :)\n>     # absolute path important\n>     autoload -Uz $PWD/contrib/completion/git-completion.zsh\n>     compdef git-completion.zsh git\n>\n>     git -C <tab>\n>\n> and it does prioritize directories there (though I still get a listing\n> of files afterwards, so the screen is taken up by that gigantic listing\n> in git.git, for example).\n>\n> By the way, I've realized that \"git -<tab>\" has the same problem (a\n> giant list of files after the other option completions), and worse has\n> some _funky_ output!\n>\n>     git -<tab> # without patch\n>     (option)\n>     --bare\n>     --exec-path\n>     --git-dir\n>     --help\n>     --html-path\n>     --info-path\n>     --man-path\n>     --namespace\n>     --no-pager\n>     --no-replace-objects\n>     --paginate\n>     --version\n>     --work-tree\n>\n>     -p\n>\n>     # treat the repository as a bare repository\n>     # path to where your core git programs are installed\n>     # set the path to the repository\n>     # prints the synopsis and a list of the most commonly used commands\n>     # print the path where gits HTML documentation is installed\n>     # print the path where the Info files are installed\n>     # print the manpath (see `man(1)`) for the man pages\n>     # set the git namespace\n>     # do not pipe git output into a pager\n>     # do not use replacement refs to replace git objects\n>     # pipe all output into less\n>     # prints the git suite version\n>     # set the path to the working tree\n>     [ed: the above block repeats twice more before the (file) listing below]\n>     (file)\n>     […]\n>\n> Here's the output of _complete_help (^Xh by default) in both situations,\n> in case that helps to understand either the extra files listing (1) in\n> the example further back or the issue with single letter options (2)\n> just mentioned:\n>\n> 1: tags in context :completion::complete:git::\n>     option-C-1     (_arguments __git_zsh_main _git git-completion.zsh)\n>     use-compctl    (_default _git git-completion.zsh)\n>     globbed-files  (_files _default _git git-completion.zsh)\n> tags in context :completion::complete:git:option-C-1:\n>     directories    (_directories _arguments __git_zsh_main _git\n> git-completion.zsh)\n>     globbed-files  (_files _directories _arguments __git_zsh_main _git\n> git-completion.zsh)\n>     all-files      (_files _directories _arguments __git_zsh_main _git\n> git-completion.zsh)\n>\n> 2: tags in context :completion::complete:git::\n>     argument-1 options  (_arguments __git_zsh_main _git)\n>     use-compctl         (_default _git)\n>     globbed-files       (_files _default _git)\n> tags in context :completion::complete:git:argument-1:\n>     common-commands alias-commands all-commands  (__git_zsh_main _git)\n>     common-commands                              (__git_zsh_cmd_common\n> __git_zsh_main _git)\n>     alias-commands                               (__git_zsh_cmd_alias\n> __git_zsh_main _git)\n>     all-commands                                 (__git_zsh_cmd_all\n> __git_zsh_main _git)\n> tags in context :completion::complete:git:options:\n>     options  (_arguments __git_zsh_main _git)\n>\n> > +        '*-C[run as if git was started in <path>]: :_directories' \\\n>\n> We should probably note in the log message that the _directories\n> completion will not account for previous -C; that is, after typing\n>\n>     git -C dir -C <tab>\n>\n> we will complete directories in \".\", not \"dir\". That's probably a\n> reasonable limitation for now, but I think we could do _slightly_ better\n> by using a state \"->dir\" or something, accumulating the current prefix,\n> and passing that to _directories as a prefix with -W (see _path_files in\n> zshcompsys, which _directories delegates to via _files, IIUC).\n>\n> --\n> D. Ben Knoble\n\nAny progress here? I just found my local copy of this patch and was\nbriefly surprised to see it hadn't graduated anywhere (until I\nrealized conversation had stalled at this point).\n\n-- \nD. Ben Knoble\n"},{"id":"550721","messageId":"a6a9fe7c-e46d-462f-b3b0-7ae6c2d52fe4@app.fastmail.com","threadId":"65823","inReplyTo":"CALnO6CB1vJ7RtBzTUSJSfYtfH+W2MZCFEkqNWeBXbWJ2r3Pdyg@mail.gmail.com","subject":"Re: [PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"Lutz Lengemann","fromEmail":"lutz@lengemann.net","sentAt":"2026-08-17T19:29:05Z","receivedAt":"2026-08-17T19:29:32Z","isPatch":true,"body":"Hi Ben\n\n(Resending, my earlier reply was rejected by the list for being HTML.)\n\nOn Wed, Jul 15, 2026, at 00:34, D. Ben Knoble wrote:\n> Any progress here? I just found my local copy of this patch and was\n> briefly surprised to see it hadn't graduated anywhere (until I\n> realized conversation had stalled at this point).\n\nSorry for the very late reply, I was on holiday and then other life\nthings got in the way of answering :(  I do have a v2 ready, which I\nhave just pushed to my fork, and which follows this message.\n\nJunio C Hamano <gitster@pobox.com> writes:\n\n> Doesn't it want to do something similar to what __git_main in\n> git-completion.bash does at the beginning, namely, this part?\n\nIt does, thanks.  v2 no longer skips only leading -C options, but walks\nthe words in front of the command and skips over the global options and,\nwhere they take one, their arguments, like __git_main does.\n\nThat also makes \"git -p checkout <TAB>\" and \"git --git-dir=<path>\ncheckout <TAB>\" complete the arguments of the command, which they did\nnot before.\n\nTwo related gaps are left alone, as they are bugs in the _arguments\nspecification rather than in the command lookup: -c is not listed there\nat all, and --git-dir and friends are spelled \"--git-dir=-\", which\naccepts only \"--git-dir=<path>\", not the \"--git-dir <path>\" form.  I can\nsend patches for those separately.\n\n\"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n\n> But we mark these local, so how do they propagate to the other\n> functions?\n\nzsh scoping is dynamic, not lexical, so a variable declared \"local\" in\n__git_zsh_main is visible in the functions that are called from it, the\nbash helpers included.  That is how __git_dir and __git_cmd_idx are\nhanded down already, and __git_C_args works the same way.\n\n> We should probably note in the log message that the _directories\n> completion will not account for previous -C\n\nI added a note about this in the log message.\n\n> I think we could do _slightly_ better by using a state \"->dir\" or\n> something, accumulating the current prefix, and passing that to\n> _directories as a prefix with -W\n\nI tried that and it works, but it changes what -C offers, which is more\nthan fixing the completion after -C, so I left it out; happy to send it\non top.  Two things to watch out for there: the accumulated path has to\nbe made absolute, as -W with \"..\" gave me the directories of \"/\", and\nthe accumulation has to stop before the word that is being completed.\n\n> By the way, I've realized that \"git -<tab>\" has the same problem (a\n> giant list of files after the other option completions)\n\nThat one is older than this patch: the file listing comes from the\nfallback at the end of _git,\n\n\tlet _ret && _default && _ret=0\n\nwhich is where the \"use-compctl\" and \"globbed-files\" tags in your\n_complete_help dump come from.  I could not reproduce the repeated\ndescription block with \"zsh -f\" and only the _complete completer, so\nsomething in my setup or yours may differ there.  Either way it wants\nits own topic.\n\nI hope that the change now looks good, and if there is anything I should\nstill look at just tell me.\n\nThank you very much\nLutz\n"},{"id":"550745","messageId":"CALnO6CCWADaQycF7XcCFLDgCVtkTAsndKykAWzNhPqVAKWYGzA@mail.gmail.com","threadId":"65823","inReplyTo":"a6a9fe7c-e46d-462f-b3b0-7ae6c2d52fe4@app.fastmail.com","subject":"Re: [PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-18T12:13:03Z","receivedAt":"2026-08-18T12:13:15Z","isPatch":true,"body":"On Mon, Aug 17, 2026 at 3:29 PM Lutz Lengemann <lutz@lengemann.net> wrote:\n>\n> Hi Ben\n>\n> (Resending, my earlier reply was rejected by the list for being HTML.)\n>\n> On Wed, Jul 15, 2026, at 00:34, D. Ben Knoble wrote:\n> > Any progress here? I just found my local copy of this patch and was\n> > briefly surprised to see it hadn't graduated anywhere (until I\n> > realized conversation had stalled at this point).\n>\n> Sorry for the very late reply, I was on holiday and then other life\n> things got in the way of answering :(  I do have a v2 ready, which I\n> have just pushed to my fork, and which follows this message.\n\nNo worries! Hope you enjoyed. (I didn't see v2 come in anywhere, but\nI'll keep my eye out.)\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n> > Doesn't it want to do something similar to what __git_main in\n> > git-completion.bash does at the beginning, namely, this part?\n>\n> It does, thanks.  v2 no longer skips only leading -C options, but walks\n> the words in front of the command and skips over the global options and,\n> where they take one, their arguments, like __git_main does.\n>\n> That also makes \"git -p checkout <TAB>\" and \"git --git-dir=<path>\n> checkout <TAB>\" complete the arguments of the command, which they did\n> not before.\n\nNice side-effect :)\n\n> Two related gaps are left alone, as they are bugs in the _arguments\n> specification rather than in the command lookup: -c is not listed there\n> at all,\n\n[no comment]\n\n> and --git-dir and friends are spelled \"--git-dir=-\", which\n> accepts only \"--git-dir=<path>\", not the \"--git-dir <path>\" form.  I can\n> send patches for those separately.\n\nWe were discussing this recently in some threads about Bash\ncompletion, and I think we landed on \"gitcli(1) really prefers the\nstuck form, and so do completion helpers, so let's stick with that for\nnow\" ?\n\n>\n> \"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n>\n> > But we mark these local, so how do they propagate to the other\n> > functions?\n>\n> zsh scoping is dynamic, not lexical, so a variable declared \"local\" in\n> __git_zsh_main is visible in the functions that are called from it, the\n> bash helpers included.  That is how __git_dir and __git_cmd_idx are\n> handed down already, and __git_C_args works the same way.\n\nThanks. I must have known that, but it's remarkably difficult to find\nspelled out in the manual. The closest I can find is the \"LOCAL\nPARAMETERS\" section of zshparam(1), which could really use an example\nto demonstrate that local is still dynamic.\n\n> > We should probably note in the log message that the _directories\n> > completion will not account for previous -C\n>\n> I added a note about this in the log message.\n\nGreat\n\n> > I think we could do _slightly_ better by using a state \"->dir\" or\n> > something, accumulating the current prefix, and passing that to\n> > _directories as a prefix with -W\n>\n> I tried that and it works, but it changes what -C offers, which is more\n> than fixing the completion after -C, so I left it out; happy to send it\n> on top.  Two things to watch out for there: the accumulated path has to\n> be made absolute, as -W with \"..\" gave me the directories of \"/\", and\n> the accumulation has to stop before the word that is being completed.\n\nA follow-up is fine with me if you decide to send it (and if not,\nthat's fine, too).\n\n> > By the way, I've realized that \"git -<tab>\" has the same problem (a\n> > giant list of files after the other option completions)\n>\n> That one is older than this patch: the file listing comes from the\n> fallback at the end of _git,\n>\n>         let _ret && _default && _ret=0\n>\n> which is where the \"use-compctl\" and \"globbed-files\" tags in your\n> _complete_help dump come from.\n\nThanks for explaining!\n\n> I could not reproduce the repeated\n> description block with \"zsh -f\" and only the _complete completer, so\n> something in my setup or yours may differ there.  Either way it wants\n> its own topic.\n\nYes, I agree that can be its own topic. I've been re-studying the\ncompletion system again recently, so maybe I'll be better equipped to\ndebug my setup later… I do play with the tag-order style for Git\ncompletions, so I wonder if that's interfering.\n\nThanks!\n\n-- \nD. Ben Knoble\n"},{"id":"550747","messageId":"43bc34ae-451d-4270-84a6-bbbf8de80115@app.fastmail.com","threadId":"65823","inReplyTo":"CALnO6CCWADaQycF7XcCFLDgCVtkTAsndKykAWzNhPqVAKWYGzA@mail.gmail.com","subject":"Re: [PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"Lutz Lengemann","fromEmail":"lutz@lengemann.net","sentAt":"2026-08-18T12:40:47Z","receivedAt":"2026-08-18T12:41:13Z","isPatch":true,"body":"Hi\n\nOn Tue, Aug 18, 2026, at 14:13, D. Ben Knoble wrote:\n> No worries! Hope you enjoyed. (I didn't see v2 come in anywhere, but\n> I'll keep my eye out.)\n\nI pushed the new change to my github repo, and then the PullRequest here was \nupdated: https://github.com/gitgitgadget/git/pull/2155/changes\n\n> > and --git-dir and friends are spelled \"--git-dir=-\", which\n> > accepts only \"--git-dir=<path>\", not the \"--git-dir <path>\" form.  I can\n> > send patches for those separately.\n> \n> We were discussing this recently in some threads about Bash\n> completion, and I think we landed on \"gitcli(1) really prefers the\n> stuck form, and so do completion helpers, so let's stick with that for\n> now\" ?\n\nOk, sound good.\n\n> > I tried that and it works, but it changes what -C offers, which is more\n> > than fixing the completion after -C, so I left it out; happy to send it\n> > on top.  Two things to watch out for there: the accumulated path has to\n> > be made absolute, as -W with \"..\" gave me the directories of \"/\", and\n> > the accumulation has to stop before the word that is being completed.\n> \n> A follow-up is fine with me if you decide to send it (and if not,\n> that's fine, too).\n\nLets see if Ican find the time for that ;)\n\nWould really love to see the change in git, makes me a bit proud that I \nadded something to the one application almost all developers use.\n\nRegards\n\nLutz\n"},{"id":"550765","messageId":"CALnO6CCFRAOouPALFdGhN1HjRuPhDj_inRBaWhebwCiD68R9AQ@mail.gmail.com","threadId":"65823","inReplyTo":"43bc34ae-451d-4270-84a6-bbbf8de80115@app.fastmail.com","subject":"Re: [PATCH] completion: zsh: support completion after \"git -C <path>\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-18T16:35:12Z","receivedAt":"2026-08-18T16:35:24Z","isPatch":true,"body":"On Tue, Aug 18, 2026 at 8:41 AM Lutz Lengemann <lutz@lengemann.net> wrote:\n>\n> Hi\n>\n> On Tue, Aug 18, 2026, at 14:13, D. Ben Knoble wrote:\n> > No worries! Hope you enjoyed. (I didn't see v2 come in anywhere, but\n> > I'll keep my eye out.)\n>\n> I pushed the new change to my github repo, and then the PullRequest here was\n> updated: https://github.com/gitgitgadget/git/pull/2155/changes\n\nAh, if you intended to send that to the mailing list, you'd need to\n/submit again, I think.\n\n> Would really love to see the change in git, makes me a bit proud that I\n> added something to the one application almost all developers use.\n\nDefinitely understand that feeling ;)\n\n-- \nD. Ben Knoble\n"},{"id":"550813","messageId":"pull.2155.v2.git.1787144872870.gitgitgadget@gmail.com","threadId":"65823","inReplyTo":"pull.2155.git.1781710256081.gitgitgadget@gmail.com","subject":"[PATCH v2] completion: zsh: support completion after \"git -C <path>\"","fromName":"Lutz Lengemann via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-08-19T13:07:51Z","receivedAt":"2026-08-19T13:07:55Z","isPatch":true,"body":"From: Lutz Lengemann <lutz@lengemann.net>\n\nThe zsh completion wrapper does not handle the global -C option, so\n\n\tgit -C <path> <command> <TAB>\n\noffers nothing.  -C is not part of the _arguments specification, and the\nwrapper hard-codes __git_cmd_idx=1, i.e. it assumes that the command is\nthe first argument, so the bash helpers look at the wrong word.  The\nlatter is not specific to -C; the assumption breaks after any global\noption, e.g. \"git -p checkout <TAB>\" does not complete branch names.\n\nAdd -C to the specification, and find the command by skipping over the\nglobal options and, where they take one, their arguments, as __git_main\nin git-completion.bash does.  The index is one less than zsh's, as the\nhelpers count the words from zero.  Collect the paths given to -C into\n__git_C_args, or else the helpers run git in the current directory and\nfail to resolve the aliases and refs of the repository the command runs\nin.\n\nThe argument of a -C is still completed without regard for the -C\noptions before it, i.e. \"git -C dir -C <TAB>\" offers the directories in\n\".\", not the ones in \"dir\".\n\nSigned-off-by: Lutz Lengemann <lutz@lengemann.net>\n---\n    completion: zsh: support completion after \"git -C \"\n    \n     * The command is now located by walking the global options in front of\n       it, mirroring the loop at the beginning of __git_main in\n       git-completion.bash, instead of skipping only leading -C options.\n       This also fixes argument completion after other global options, e.g.\n       git -p checkout <TAB>.\n     * The log message uses the present tense for the pre-image and notes\n       that the argument of a -C is completed without regard for the -C\n       options before it.\n    \n    cc: Ben Knoble ben.knoble@gmail.com cc: Junio C Hamano gitster@pobox.com\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2155%2Fmobilutz%2Fzsh-complete-global-C-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2155/mobilutz/zsh-complete-global-C-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/2155\n\nRange-diff vs v1:\n\n 1:  9739cde6fc ! 1:  9984228f1f completion: zsh: support completion after \"git -C <path>\"\n     @@ Metadata\n       ## Commit message ##\n          completion: zsh: support completion after \"git -C <path>\"\n      \n     -    The zsh completion wrapper (__git_zsh_main) did not handle the global -C\n     -    option, so \"git -C <path> <command> <TAB>\" offered nothing and could not\n     -    complete a command's arguments.\n     +    The zsh completion wrapper does not handle the global -C option, so\n      \n     -    Three things are needed to make it work, all scoped to -C:\n     +            git -C <path> <command> <TAB>\n      \n     -      - Add -C to the _arguments specification, so completion no longer stops\n     -        at it.\n     +    offers nothing.  -C is not part of the _arguments specification, and the\n     +    wrapper hard-codes __git_cmd_idx=1, i.e. it assumes that the command is\n     +    the first argument, so the bash helpers look at the wrong word.  The\n     +    latter is not specific to -C; the assumption breaks after any global\n     +    option, e.g. \"git -p checkout <TAB>\" does not complete branch names.\n      \n     -      - Advance __git_cmd_idx past any leading \"-C <path>\" options. The index\n     -        is hard-coded to 1, i.e. the command is assumed to be the first\n     -        argument; with -C present the command sits two words later for each\n     -        -C, so the bash helpers otherwise look at the wrong word and produce\n     -        nothing.\n     +    Add -C to the specification, and find the command by skipping over the\n     +    global options and, where they take one, their arguments, as __git_main\n     +    in git-completion.bash does.  The index is one less than zsh's, as the\n     +    helpers count the words from zero.  Collect the paths given to -C into\n     +    __git_C_args, or else the helpers run git in the current directory and\n     +    fail to resolve the aliases and refs of the repository the command runs\n     +    in.\n      \n     -      - Collect the -C paths into __git_C_args, as __git_main does. The bash\n     -        helpers run git to resolve aliases and list refs; without the -C\n     -        paths they run in the current directory, so completion fails whenever\n     -        the cwd is not the target repository or the command is an alias.\n     -\n     -    With these, \"git -C <path> <command> <TAB>\" completes the command, its\n     -    options and its arguments, including outside the repository, through\n     -    aliases, and with repeated -C options.\n     +    The argument of a -C is still completed without regard for the -C\n     +    options before it, i.e. \"git -C dir -C <TAB>\" offers the directories in\n     +    \".\", not the ones in \"dir\".\n      \n          Signed-off-by: Lutz Lengemann <lutz@lengemann.net>\n      \n     @@ contrib/completion/git-completion.zsh: __git_zsh_main ()\n       \t\t'(- :)--version[prints the git suite version]' \\\n       \t\t'--exec-path=-[path to where your core git programs are installed]:: :_directories' \\\n      @@ contrib/completion/git-completion.zsh: __git_zsh_main ()\n     + \t\tdone\n       \t\t;;\n       \t(arg)\n     - \t\tlocal command=\"${words[1]}\" __git_dir __git_cmd_idx=1\n     +-\t\tlocal command=\"${words[1]}\" __git_dir __git_cmd_idx=1\n     ++\t\tlocal command=\"${words[1]}\" __git_dir __git_cmd_idx\n      +\t\tlocal -a __git_C_args\n      +\t\tlocal -i i=2\n      +\n     -+\t\twhile [[ ${orig_words[i]} == -C ]]; do\n     -+\t\t\t__git_C_args+=(-C ${orig_words[i+1]})\n     -+\t\t\t(( __git_cmd_idx += 2 ))\n     -+\t\t\t(( i += 2 ))\n     ++\t\twhile (( i <= $#orig_words )); do\n     ++\t\t\tcase ${orig_words[i]} in\n     ++\t\t\t-C)\n     ++\t\t\t\t__git_C_args+=(-C ${orig_words[i+1]})\n     ++\t\t\t\t(( i++ ))\n     ++\t\t\t\t;;\n     ++\t\t\t-c|--git-dir|--work-tree|--namespace)\n     ++\t\t\t\t(( i++ ))\n     ++\t\t\t\t;;\n     ++\t\t\t-*)\n     ++\t\t\t\t;;\n     ++\t\t\t*)\n     ++\t\t\t\tbreak\n     ++\t\t\t\t;;\n     ++\t\t\tesac\n     ++\t\t\t(( i++ ))\n      +\t\tdone\n     ++\n     ++\t\t__git_cmd_idx=$(( i - 1 ))\n       \n       \t\tif (( $+opt_args[--bare] )); then\n       \t\t\t__git_dir='.'\n\n\n contrib/completion/git-completion.zsh | 25 ++++++++++++++++++++++++-\n 1 file changed, 24 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh\nindex c32186a977..d5c526665b 100644\n--- a/contrib/completion/git-completion.zsh\n+++ b/contrib/completion/git-completion.zsh\n@@ -227,6 +227,7 @@ __git_zsh_main ()\n \t\t'(-p --paginate --no-pager)'{-p,--paginate}'[pipe all output into ''less'']' \\\n \t\t'(-p --paginate)--no-pager[do not pipe git output into a pager]' \\\n \t\t'--git-dir=-[set the path to the repository]: :_directories' \\\n+\t\t'*-C[run as if git was started in <path>]: :_directories' \\\n \t\t'--bare[treat the repository as a bare repository]' \\\n \t\t'(- :)--version[prints the git suite version]' \\\n \t\t'--exec-path=-[path to where your core git programs are installed]:: :_directories' \\\n@@ -251,7 +252,29 @@ __git_zsh_main ()\n \t\tdone\n \t\t;;\n \t(arg)\n-\t\tlocal command=\"${words[1]}\" __git_dir __git_cmd_idx=1\n+\t\tlocal command=\"${words[1]}\" __git_dir __git_cmd_idx\n+\t\tlocal -a __git_C_args\n+\t\tlocal -i i=2\n+\n+\t\twhile (( i <= $#orig_words )); do\n+\t\t\tcase ${orig_words[i]} in\n+\t\t\t-C)\n+\t\t\t\t__git_C_args+=(-C ${orig_words[i+1]})\n+\t\t\t\t(( i++ ))\n+\t\t\t\t;;\n+\t\t\t-c|--git-dir|--work-tree|--namespace)\n+\t\t\t\t(( i++ ))\n+\t\t\t\t;;\n+\t\t\t-*)\n+\t\t\t\t;;\n+\t\t\t*)\n+\t\t\t\tbreak\n+\t\t\t\t;;\n+\t\t\tesac\n+\t\t\t(( i++ ))\n+\t\tdone\n+\n+\t\t__git_cmd_idx=$(( i - 1 ))\n \n \t\tif (( $+opt_args[--bare] )); then\n \t\t\t__git_dir='.'\n\nbase-commit: 0fae78c9d55efe705877ea537fe42c59164ccd94\n-- \ngitgitgadget\n"},{"id":"550896","messageId":"CALnO6CC35iuyJpKZtkEN7fGuGK7zKd_jbebyZdKSQ1pyfOBRZA@mail.gmail.com","threadId":"65823","inReplyTo":"pull.2155.v2.git.1787144872870.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] completion: zsh: support completion after \"git -C <path>\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-20T12:28:33Z","receivedAt":"2026-08-20T12:28:45Z","isPatch":true,"body":"On Wed, Aug 19, 2026 at 9:07 AM Lutz Lengemann via GitGitGadget\n<gitgitgadget@gmail.com> wrote:\n>\n> From: Lutz Lengemann <lutz@lengemann.net>\n>\n> The zsh completion wrapper does not handle the global -C option, so\n>\n>         git -C <path> <command> <TAB>\n>\n> offers nothing.  -C is not part of the _arguments specification, and the\n> wrapper hard-codes __git_cmd_idx=1, i.e. it assumes that the command is\n> the first argument, so the bash helpers look at the wrong word.  The\n> latter is not specific to -C; the assumption breaks after any global\n> option, e.g. \"git -p checkout <TAB>\" does not complete branch names.\n>\n> Add -C to the specification, and find the command by skipping over the\n> global options and, where they take one, their arguments, as __git_main\n> in git-completion.bash does.  The index is one less than zsh's, as the\n> helpers count the words from zero.  Collect the paths given to -C into\n> __git_C_args, or else the helpers run git in the current directory and\n> fail to resolve the aliases and refs of the repository the command runs\n> in.\n>\n> The argument of a -C is still completed without regard for the -C\n> options before it, i.e. \"git -C dir -C <TAB>\" offers the directories in\n> \".\", not the ones in \"dir\".\n>\n> Signed-off-by: Lutz Lengemann <lutz@lengemann.net>\n> ---\n>     completion: zsh: support completion after \"git -C \"\n>\n>      * The command is now located by walking the global options in front of\n>        it, mirroring the loop at the beginning of __git_main in\n>        git-completion.bash, instead of skipping only leading -C options.\n>        This also fixes argument completion after other global options, e.g.\n>        git -p checkout <TAB>.\n>      * The log message uses the present tense for the pre-image and notes\n>        that the argument of a -C is completed without regard for the -C\n>        options before it.\n>\n>     cc: Ben Knoble ben.knoble@gmail.com cc: Junio C Hamano gitster@pobox.com\n>\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2155%2Fmobilutz%2Fzsh-complete-global-C-v2\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2155/mobilutz/zsh-complete-global-C-v2\n> Pull-Request: https://github.com/gitgitgadget/git/pull/2155\n>\n> Range-diff vs v1:\n>\n>  1:  9739cde6fc ! 1:  9984228f1f completion: zsh: support completion after \"git -C <path>\"\n>      @@ Metadata\n[snip]\n>\n>           Signed-off-by: Lutz Lengemann <lutz@lengemann.net>\n>\n>      @@ contrib/completion/git-completion.zsh: __git_zsh_main ()\n>                 '(- :)--version[prints the git suite version]' \\\n>                 '--exec-path=-[path to where your core git programs are installed]:: :_directories' \\\n>       @@ contrib/completion/git-completion.zsh: __git_zsh_main ()\n>      +          done\n>                 ;;\n>         (arg)\n>      -          local command=\"${words[1]}\" __git_dir __git_cmd_idx=1\n>      +-         local command=\"${words[1]}\" __git_dir __git_cmd_idx=1\n>      ++         local command=\"${words[1]}\" __git_dir __git_cmd_idx\n\nOk, this matches what the message describes about __git_cmd_idx not\nbeing able to assume=1; it's different in this version because we are\na bit more sophisticated in our parsing.\n\n>       +         local -a __git_C_args\n>       +         local -i i=2\n>       +\n>      -+         while [[ ${orig_words[i]} == -C ]]; do\n>      -+                 __git_C_args+=(-C ${orig_words[i+1]})\n>      -+                 (( __git_cmd_idx += 2 ))\n>      -+                 (( i += 2 ))\n>      ++         while (( i <= $#orig_words )); do\n>      ++                 case ${orig_words[i]} in\n>      ++                 -C)\n>      ++                         __git_C_args+=(-C ${orig_words[i+1]})\n>      ++                         (( i++ ))\n\nAt first I thought \"should that be i+=2?\"; then I saw the\nunconditional i++ later. Reasonable, though I'm not sure what happens\nif we walk off the end of the array here: If i=#orig_words, then\n__git_C_args has (-C) and i becomes #orig_words+2; later,\n__git_cmd_idx becomes #orig_words+1, which is empty. I'll keep that in\nmind when looking at how we handle those variables.\n\n…Ok, those are handled in the Bash completion. AFAICT, they don't do\nanything special when the dir is missing either. A bit strange, but\nnot something this patch needs to solve, I suppose. __git_cmd_idx is\nused many places, as we would imagine, and I didn't look carefully at\nwhat happens when it indexes an empty spot (but it looks to mostly be\nused in comparisons where that would just go falsy, or in arithmetic I\nhaven't really checked at all).\n\n(I also haven't thought carefully about the difference between Zsh's\n1-based indexing and Bash's 0-based, so I'm not sure if there's an\nissue lurking there.)\n\n>      ++                         ;;\n>      ++                 -c|--git-dir|--work-tree|--namespace)\n>      ++                         (( i++ ))\n>      ++                         ;;\n>      ++                 -*)\n>      ++                         ;;\n\nYep, unlike Bash (which requires at least one command in the \"list\"\npart between a pattern and the terminator), Zsh accepts empty actions\nhere.\n\n>      ++                 *)\n>      ++                         break\n>      ++                         ;;\n>      ++                 esac\n>      ++                 (( i++ ))\n>       +         done\n>      ++\n>      ++         __git_cmd_idx=$(( i - 1 ))\n>\n>                 if (( $+opt_args[--bare] )); then\n>                         __git_dir='.'\n>\n>\n>  contrib/completion/git-completion.zsh | 25 ++++++++++++++++++++++++-\n>  1 file changed, 24 insertions(+), 1 deletion(-)\n>\n> diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh\n> index c32186a977..d5c526665b 100644\n> --- a/contrib/completion/git-completion.zsh\n> +++ b/contrib/completion/git-completion.zsh\n> @@ -227,6 +227,7 @@ __git_zsh_main ()\n>                 '(-p --paginate --no-pager)'{-p,--paginate}'[pipe all output into ''less'']' \\\n>                 '(-p --paginate)--no-pager[do not pipe git output into a pager]' \\\n>                 '--git-dir=-[set the path to the repository]: :_directories' \\\n> +               '*-C[run as if git was started in <path>]: :_directories' \\\n\nAt first I wasn't sure about the blank description (space between 2\ncolons) of the argument to -C, but I see that _directories\nautomatically describes the completed thing as \"directory,\" so that's\nfine.\n\nOverall, if this version works, I think I'm happy with it. Confirming\nthe index math works out between the 2 shells might be a useful\nexercise, but /shrug.\n\n-- \nD. Ben Knoble\n"},{"id":"550952","messageId":"xmqqo6ewtqs8.fsf@gitster.g","threadId":"65823","inReplyTo":"CALnO6CC35iuyJpKZtkEN7fGuGK7zKd_jbebyZdKSQ1pyfOBRZA@mail.gmail.com","subject":"Re: [PATCH v2] completion: zsh: support completion after \"git -C <path>\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-20T21:39:51Z","receivedAt":"2026-08-20T21:39:54Z","isPatch":true,"body":"\"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n\n>>      ++                         ;;\n>>      ++                 -c|--git-dir|--work-tree|--namespace)\n>>      ++                         (( i++ ))\n>>      ++                         ;;\n>>      ++                 -*)\n>>      ++                         ;;\n>\n> Yep, unlike Bash (which requires at least one command in the \"list\"\n> part between a pattern and the terminator), Zsh accepts empty actions\n> here.\n\nThis may be a common misconception.\n\nIt is true that a compound_list is not allowed to be empty, but\nPOSIX.1 sh grammar [*] explicitly allows ';;' to come after ')'\nwithout a compound_list in between.\n\nSpecifically\n\n        case_item        :     pattern ')' linebreak     DSEMI linebreak\n                         |     pattern ')' compound_list DSEMI linebreak\n                         | '(' pattern ')' linebreak     DSEMI linebreak\n                         | '(' pattern ')' compound_list DSEMI linebreak\n                         ;\n\nwhere \"linebreak\" is a run of NEWLINE tokens or empty.  So\n\n\tcase $foo in\n\tbar) ;;\n\tesac\n\nis allowed.\n\n\n[Footnote]\n\n* Look for case_clause in\n  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html\n  and read from there.\n"},{"id":"551009","messageId":"CALnO6CCr+CMhB6Pxo7KHExcJ7PBcEQODEJa_PmfguCr_WYVS+A@mail.gmail.com","threadId":"65823","inReplyTo":"xmqqo6ewtqs8.fsf@gitster.g","subject":"Re: [PATCH v2] completion: zsh: support completion after \"git -C <path>\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-21T12:31:46Z","receivedAt":"2026-08-21T12:31:57Z","isPatch":true,"body":"On Thu, Aug 20, 2026 at 5:39 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> \"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n>\n> >>      ++                         ;;\n> >>      ++                 -c|--git-dir|--work-tree|--namespace)\n> >>      ++                         (( i++ ))\n> >>      ++                         ;;\n> >>      ++                 -*)\n> >>      ++                         ;;\n> >\n> > Yep, unlike Bash (which requires at least one command in the \"list\"\n> > part between a pattern and the terminator), Zsh accepts empty actions\n> > here.\n>\n> This may be a common misconception.\n>\n> It is true that a compound_list is not allowed to be empty, but\n> POSIX.1 sh grammar [*] explicitly allows ';;' to come after ')'\n> without a compound_list in between.\n>\n> Specifically\n>\n>         case_item        :     pattern ')' linebreak     DSEMI linebreak\n>                          |     pattern ')' compound_list DSEMI linebreak\n>                          | '(' pattern ')' linebreak     DSEMI linebreak\n>                          | '(' pattern ')' compound_list DSEMI linebreak\n>                          ;\n>\n> where \"linebreak\" is a run of NEWLINE tokens or empty.  So\n>\n>         case $foo in\n>         bar) ;;\n>         esac\n>\n> is allowed.\n>\n>\n> [Footnote]\n>\n> * Look for case_clause in\n>   https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html\n>   and read from there.\n\nOh, thanks! The Bash manual doesn't admit that case in my reading, but\nit clearly does in implementation. Oddly, I seem to recall several\nyears ago that both Bash and ShellCheck would complain about empty\ncase arms (I got in the habit of writing \": continue\" as a bit of a\ncomment). Anyway, TIL.\n\n-- \nD. Ben Knoble\n"},{"id":"551031","messageId":"xmqq5x13qvb5.fsf@gitster.g","threadId":"65823","inReplyTo":"CALnO6CCr+CMhB6Pxo7KHExcJ7PBcEQODEJa_PmfguCr_WYVS+A@mail.gmail.com","subject":"Re: [PATCH v2] completion: zsh: support completion after \"git -C <path>\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-21T16:42:38Z","receivedAt":"2026-08-21T16:42:44Z","isPatch":true,"body":"\"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n\n>> [Footnote]\n>>\n>> * Look for case_clause in\n>>   https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html\n>>   and read from there.\n>\n> Oh, thanks! The Bash manual doesn't admit that case in my reading, but\n> it clearly does in implementation. Oddly, I seem to recall several\n> years ago that both Bash and ShellCheck would complain about empty\n> case arms (I got in the habit of writing \": continue\" as a bit of a\n> comment). Anyway, TIL.\n\nI am afraid that the description in POSIX itself contributes heavily\nto this common misconception.\n\nSection 2.9.4.3 (Case Conditional Construct)\n\nhttps://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_09_04_05\n\ngives a simplified syntax\n\n    The format for the case construct is as follows:\n\n    case word in\n        [[(] pattern[ | pattern] ... ) compound-list terminator] ...\n        [[(] pattern[ | pattern] ... ) compound-list]\n    esac\n\nand I think that is where the most people go to learn what is and\nwhat is not kosher in the standard.  But as you saw, this simplified\n\"format\" contradicts what the actual grammar, described in Section\n2.10 (Shell Grammar) has (notably, you can have linebreak, which is\ndefined to be zero or more NEWLINEs, instead of compound-list\nthere).\n\nhttps://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_10\n"},{"id":"551321","messageId":"xmqqld9sczd0.fsf@gitster.g","threadId":"65823","inReplyTo":"pull.2155.v2.git.1787144872870.gitgitgadget@gmail.com","subject":"Re: [PATCH v2] completion: zsh: support completion after \"git -C <path>\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-26T22:04:43Z","receivedAt":"2026-08-26T22:04:46Z","isPatch":true,"body":"\"Lutz Lengemann via GitGitGadget\" <gitgitgadget@gmail.com> writes:\n\n> From: Lutz Lengemann <lutz@lengemann.net>\n>\n> The zsh completion wrapper does not handle the global -C option, so\n>\n> \tgit -C <path> <command> <TAB>\n>\n> offers nothing.  -C is not part of the _arguments specification, and the\n> wrapper hard-codes __git_cmd_idx=1, i.e. it assumes that the command is\n> the first argument, so the bash helpers look at the wrong word.  The\n> latter is not specific to -C; the assumption breaks after any global\n> option, e.g. \"git -p checkout <TAB>\" does not complete branch names.\n>\n> Add -C to the specification, and find the command by skipping over the\n> global options and, where they take one, their arguments, as __git_main\n> in git-completion.bash does.  The index is one less than zsh's, as the\n> helpers count the words from zero.  Collect the paths given to -C into\n> __git_C_args, or else the helpers run git in the current directory and\n> fail to resolve the aliases and refs of the repository the command runs\n> in.\n>\n> The argument of a -C is still completed without regard for the -C\n> options before it, i.e. \"git -C dir -C <TAB>\" offers the directories in\n> \".\", not the ones in \"dir\".\n>\n> Signed-off-by: Lutz Lengemann <lutz@lengemann.net>\n> ---\n\nLet me mark the topic for 'next', as later parts of the thread was\nabout an unrelated tangent.\n\n"}]}