{"thread":{"id":"66037","subject":"[PATCH] completion: complete paths for git send-email","startedAt":"2026-07-19T13:44:51Z","lastAt":"2026-07-22T15:32:45Z","messageCount":9,"participants":["Yury Norov (NVIDIA)","Junio C Hamano","D. Ben Knoble","Yury Norov","SZEDER Gábor","Ben Knoble"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"548625","messageId":"20260719134447.381835-1-yury.norov@gmail.com","threadId":"66037","inReplyTo":null,"subject":"[PATCH] completion: complete paths for git send-email","fromName":"Yury Norov (NVIDIA)","fromEmail":"yury.norov@gmail.com","sentAt":"2026-07-19T13:44:47Z","receivedAt":"2026-07-19T13:44:51Z","isPatch":true,"body":"From: Yury Norov <ynorov@nvidia.com>\n\ngit send-email accepts either revisions or paths to patch files, but its\nBash completion only offers revisions. This prevents patch files from\nbeing completed. It can also make a prefix such as \"0\" expand to an\nunrelated hexadecimal ref even when matching 0001-*.patch files exist.\n\nIn my Linux tree, an attempt to autocomplete the standard-named patch\nbrings a random hashtag:\n\n $ ls 0*\n 0001-bitmap-drop-bitmap_next_set_region.patch\n $ git send-email 0<Tab>\n $ git send-email 05c69d298c96703741cac9a5cbbf6c53bd55a6e2\n\nIntroduce an append variant of __gitcomp_file() and use it to add\nfilesystem candidates after the existing revision candidates.  Keep the\nlatter because revisions remain valid send-email arguments.\n\nAdd a regression test covering patch files alongside a 40-hex ref.\n\nAssisted-by: Codex <codex@openai.com>\nSigned-off-by: Yury Norov <ynorov@nvidia.com>\n---\n contrib/completion/git-completion.bash | 29 +++++++++++++++++++-------\n t/t9902-completion.sh                  | 12 ++++++++++-\n 2 files changed, 33 insertions(+), 8 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex e87578771..b7017488d 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -579,21 +579,18 @@ __gitcomp_file_direct ()\n }\n \n # Generates completion reply with compgen from newline-separated possible\n-# completion filenames.\n+# completion filenames by appending them to the existing list of completion\n+# candidates, COMPREPLY.\n # It accepts 1 to 3 arguments:\n # 1: List of possible completion filenames, separated by a single newline.\n # 2: A directory prefix to be added to each possible completion filename\n #    (optional).\n # 3: Generate possible completion matches for this word (optional).\n-__gitcomp_file ()\n+__gitcomp_file_append ()\n {\n \tlocal IFS=$'\\n'\n \n-\t# XXX does not work when the directory prefix contains a tilde,\n-\t# since tilde expansion is not applied.\n-\t# This means that COMPREPLY will be empty and Bash default\n-\t# completion will be used.\n-\t__gitcompadd \"$1\" \"${2-}\" \"${3-$cur}\" \"\"\n+\t__gitcompappend \"$1\" \"${2-}\" \"${3-$cur}\" \"\"\n \n \t# use a hack to enable file mode in bash < 4\n \tcompopt -o filenames +o nospace 2>/dev/null ||\n@@ -601,6 +598,23 @@ __gitcomp_file ()\n \ttrue\n }\n \n+# Generates completion reply with compgen from newline-separated possible\n+# completion filenames.\n+# It accepts 1 to 3 arguments:\n+# 1: List of possible completion filenames, separated by a single newline.\n+# 2: A directory prefix to be added to each possible completion filename\n+#    (optional).\n+# 3: Generate possible completion matches for this word (optional).\n+__gitcomp_file ()\n+{\n+\t# XXX does not work when the directory prefix contains a tilde,\n+\t# since tilde expansion is not applied.\n+\t# This means that COMPREPLY will be empty and Bash default\n+\t# completion will be used.\n+\tCOMPREPLY=()\n+\t__gitcomp_file_append \"$@\"\n+}\n+\n # Find the current subcommand for commands that follow the syntax:\n #\n #    git <command> <subcommand>\n@@ -2634,6 +2648,7 @@ _git_send_email ()\n \t\t;;\n \tesac\n \t__git_complete_revlist\n+\t__gitcomp_file_append \"$(compgen -f -- \"$cur\")\"\n }\n \n _git_stage ()\ndiff --git a/t/t9902-completion.sh b/t/t9902-completion.sh\nindex 55dc9eabf..e87827f21 100755\n--- a/t/t9902-completion.sh\n+++ b/t/t9902-completion.sh\n@@ -2777,7 +2777,17 @@ test_expect_success PERL 'send-email' '\n \ttest_completion \"git send-email --val\" <<-\\EOF &&\n \t--validate Z\n \tEOF\n-\ttest_completion \"git send-email ma\" \"main \"\n+\ttest_completion \"git send-email ma\" \"main \" &&\n+\n+\tgit tag 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 &&\n+\ttest_when_finished \"git tag -d 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 &&\n+\t\trm -f 0001-example.patch 0002-example.patch\" &&\n+\ttouch 0001-example.patch 0002-example.patch &&\n+\ttest_completion \"git send-email 0\" <<-\\EOF\n+\t0001-example.patch\n+\t0002-example.patch\n+\t05c69d298c96703741cac9a5cbbf6c53bd55a6e2 Z\n+\tEOF\n '\n \n test_expect_success 'complete files' '\n-- \n2.53.0\n\n"},{"id":"548627","messageId":"xmqqwluqnc5y.fsf@gitster.g","threadId":"66037","inReplyTo":"20260719134447.381835-1-yury.norov@gmail.com","subject":"Re: [PATCH] completion: complete paths for git send-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-19T17:04:41Z","receivedAt":"2026-07-19T17:04:44Z","isPatch":true,"body":"\"Yury Norov (NVIDIA)\" <yury.norov@gmail.com> writes:\n\n> From: Yury Norov <ynorov@nvidia.com>\n>\n> git send-email accepts either revisions or paths to patch files, but its\n> Bash completion only offers revisions. This prevents patch files from\n> being completed. It can also make a prefix such as \"0\" expand to an\n> unrelated hexadecimal ref even when matching 0001-*.patch files exist.\n>\n> In my Linux tree, an attempt to autocomplete the standard-named patch\n> brings a random hashtag:\n>\n>  $ ls 0*\n>  0001-bitmap-drop-bitmap_next_set_region.patch\n>  $ git send-email 0<Tab>\n>  $ git send-email 05c69d298c96703741cac9a5cbbf6c53bd55a6e2\n\nWow.  Even though I use nothing but 'git send-email' when sending my\nown patches, I have never noticed this behavior.  I guess that is\nprimarily because I only use the command via my own wrapper script,\nso the usual bash completion kicks in only for filenames in my\nworkflow.  Since I store my patches two levels deep in my working\ntree (for example, '+outgo/topic/0000-cover-letter.txt'), I suspect\nthat even if I got rid of my wrapper, I would not suffer from this\nissue.  An attempt to run 'git send-email +outgo/contrib-doc/0<TAB>'\nexpanding the trailing '0' into a hexadecimal object name would\nindeed be quite annoying.\n\nGood find.\n\n> Introduce an append variant of __gitcomp_file() and use it to add\n> filesystem candidates after the existing revision candidates.  Keep the\n> latter because revisions remain valid send-email arguments.\n\nOK.  I will need help from those who are more familiar with our\ncompletion code than I am to properly assess this change.  Any\nassistance in reviewing this would be appreciated.\n\n> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh\n> index 55dc9eabf..e87827f21 100755\n> --- a/t/t9902-completion.sh\n> +++ b/t/t9902-completion.sh\n> @@ -2777,7 +2777,17 @@ test_expect_success PERL 'send-email' '\n>  \ttest_completion \"git send-email --val\" <<-\\EOF &&\n>  \t--validate Z\n>  \tEOF\n> -\ttest_completion \"git send-email ma\" \"main \"\n> +\ttest_completion \"git send-email ma\" \"main \" &&\n> +\n> +\tgit tag 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 &&\n> +\ttest_when_finished \"git tag -d 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 &&\n> +\t\trm -f 0001-example.patch 0002-example.patch\" &&\n\nIf the initial 'git tag' fails, 'test_when_finished' is never\nregistered, and we end up failing to remove the '000?-example.patch'\nfiles.  The usual way to write this is:\n\n - set up 'test_when_finished' with a body that is written to\n   succeed even if the clean-up target is not present (your '-f' in\n   'rm -f' is good, as it prevents 'rm' from failing even if\n   '0001-example.patch' does not get created); then\n\n - write the test code that dirties the state (requiring clean-up)\n   after registering the 'test_when_finished' handler.\n\nThat is, \"Prepare the clean-up first, and then you do not have to\nworry about making a mess.\"\n\nBy the way, the use of a purely hexadecimal string as a tag or\nbranch name is highly misleading.  What happens if an object exists\nwhose name is identical to that tag?  Git offers ways to\ndisambiguate if you really want to, but I do not see any reason for\na sensible person or workflow to deliberately place oneself in a\nsituation where such disambiguation becomes necessary.\n\nOf course, that is no excuse for the bug.  Our completion script\nshould not misbehave, even when confronted with a workflow that uses\nfunny-looking tags.\n"},{"id":"548721","messageId":"CALnO6CAuitGp_xLYkXpkQYV9oiXsNNfsXZ_OqzkW7_6ND49=LA@mail.gmail.com","threadId":"66037","inReplyTo":"20260719134447.381835-1-yury.norov@gmail.com","subject":"Re: [PATCH] completion: complete paths for git send-email","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-07-21T12:49:54Z","receivedAt":"2026-07-21T12:50:06Z","isPatch":true,"body":"On Sun, Jul 19, 2026 at 9:45 AM Yury Norov (NVIDIA)\n<yury.norov@gmail.com> wrote:\n>\n> From: Yury Norov <ynorov@nvidia.com>\n>\n> git send-email accepts either revisions or paths to patch files, but its\n> Bash completion only offers revisions. This prevents patch files from\n> being completed. It can also make a prefix such as \"0\" expand to an\n> unrelated hexadecimal ref even when matching 0001-*.patch files exist.\n>\n> In my Linux tree, an attempt to autocomplete the standard-named patch\n> brings a random hashtag:\n\nIt is unusual to call this a \"hashtag.\" Perhaps \"hash\" or \"object\nname\" (or id) based on the glossary and datamodel docs?\n\n>  $ ls 0*\n>  0001-bitmap-drop-bitmap_next_set_region.patch\n>  $ git send-email 0<Tab>\n>  $ git send-email 05c69d298c96703741cac9a5cbbf6c53bd55a6e2\n>\n> Introduce an append variant of __gitcomp_file() and use it to add\n> filesystem candidates after the existing revision candidates.  Keep the\n> latter because revisions remain valid send-email arguments.\n>\n> Add a regression test covering patch files alongside a 40-hex ref.\n>\n> Assisted-by: Codex <codex@openai.com>\n> Signed-off-by: Yury Norov <ynorov@nvidia.com>\n> ---\n>  contrib/completion/git-completion.bash | 29 +++++++++++++++++++-------\n>  t/t9902-completion.sh                  | 12 ++++++++++-\n>  2 files changed, 33 insertions(+), 8 deletions(-)\n>\n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index e87578771..b7017488d 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -579,21 +579,18 @@ __gitcomp_file_direct ()\n>  }\n>\n>  # Generates completion reply with compgen from newline-separated possible\n> -# completion filenames.\n> +# completion filenames by appending them to the existing list of completion\n> +# candidates, COMPREPLY.\n>  # It accepts 1 to 3 arguments:\n>  # 1: List of possible completion filenames, separated by a single newline.\n>  # 2: A directory prefix to be added to each possible completion filename\n>  #    (optional).\n>  # 3: Generate possible completion matches for this word (optional).\n> -__gitcomp_file ()\n> +__gitcomp_file_append ()\n>  {\n>         local IFS=$'\\n'\n>\n> -       # XXX does not work when the directory prefix contains a tilde,\n> -       # since tilde expansion is not applied.\n> -       # This means that COMPREPLY will be empty and Bash default\n> -       # completion will be used.\n> -       __gitcompadd \"$1\" \"${2-}\" \"${3-$cur}\" \"\"\n> +       __gitcompappend \"$1\" \"${2-}\" \"${3-$cur}\" \"\"\n>\n>         # use a hack to enable file mode in bash < 4\n>         compopt -o filenames +o nospace 2>/dev/null ||\n> @@ -601,6 +598,23 @@ __gitcomp_file ()\n>         true\n>  }\n>\n> +# Generates completion reply with compgen from newline-separated possible\n> +# completion filenames.\n> +# It accepts 1 to 3 arguments:\n> +# 1: List of possible completion filenames, separated by a single newline.\n> +# 2: A directory prefix to be added to each possible completion filename\n> +#    (optional).\n> +# 3: Generate possible completion matches for this word (optional).\n> +__gitcomp_file ()\n> +{\n> +       # XXX does not work when the directory prefix contains a tilde,\n> +       # since tilde expansion is not applied.\n> +       # This means that COMPREPLY will be empty and Bash default\n> +       # completion will be used.\n> +       COMPREPLY=()\n> +       __gitcomp_file_append \"$@\"\n> +}\n> +\n\nCurious; the diff itself is much more readable for me when applied\nlocally (it shows the addition of __gitcomp_file_append and the\nreplacement of a few lines in __gitcomp_file).\n\nNonetheless, this follows the pattern established by __gitcompadd and\n__gitcompappend, so that part at least looks like it functions as\nexpected. (I can't comment too much on the code that existed there\nalready.)\n\n>  # Find the current subcommand for commands that follow the syntax:\n>  #\n>  #    git <command> <subcommand>\n> @@ -2634,6 +2648,7 @@ _git_send_email ()\n>                 ;;\n>         esac\n>         __git_complete_revlist\n> +       __gitcomp_file_append \"$(compgen -f -- \"$cur\")\"\n\nAt least with Bash with compgen, this looks to me like it does append\nfile names to the COMPREPLY.\n\nBut, with the \"hack\" comment in the modified function, do we also need\nto account for older bash? It looks like that comes from 3ffa4df4b2\n(completion: add hack to enable file mode in bash < 4, 2013-04-27).\nAfter studying a bit more, that hack is to make Bash do the right\nthing during file completion, not to workaround different methods of\ngenerating filenames (unlike Zsh, which has a newer and an older\ncompletion system, Bash's seems relatively stable?).\n\nSo, I think this looks good.\n\n>  }\n>\n>  _git_stage ()\n> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh\n> index 55dc9eabf..e87827f21 100755\n> --- a/t/t9902-completion.sh\n> +++ b/t/t9902-completion.sh\n> @@ -2777,7 +2777,17 @@ test_expect_success PERL 'send-email' '\n>         test_completion \"git send-email --val\" <<-\\EOF &&\n>         --validate Z\n>         EOF\n> -       test_completion \"git send-email ma\" \"main \"\n> +       test_completion \"git send-email ma\" \"main \" &&\n> +\n> +       git tag 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 &&\n> +       test_when_finished \"git tag -d 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 &&\n> +               rm -f 0001-example.patch 0002-example.patch\" &&\n> +       touch 0001-example.patch 0002-example.patch &&\n> +       test_completion \"git send-email 0\" <<-\\EOF\n> +       0001-example.patch\n> +       0002-example.patch\n> +       05c69d298c96703741cac9a5cbbf6c53bd55a6e2 Z\n> +       EOF\n>  '\n>\n>  test_expect_success 'complete files' '\n> --\n> 2.53.0\n\nJunio commented on the test, so I'll stop here.\n\nPending a commit message tweak for \"hashtag,\" I'm satisfied enough for\n\nReviewed-by: D. Ben Knoble <ben.knoble@gmail.com>\n\n(Or feel free to use \"Acked-by\" if this is not a strong enough review\nfor you/the project!)\n\n-- \nD. Ben Knoble\n"},{"id":"548727","messageId":"xmqqcxwgz2u3.fsf@gitster.g","threadId":"66037","inReplyTo":"CALnO6CAuitGp_xLYkXpkQYV9oiXsNNfsXZ_OqzkW7_6ND49=LA@mail.gmail.com","subject":"Re: [PATCH] completion: complete paths for git send-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-21T17:09:56Z","receivedAt":"2026-07-21T17:09:59Z","isPatch":true,"body":"\"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n\n> On Sun, Jul 19, 2026 at 9:45 AM Yury Norov (NVIDIA)\n> <yury.norov@gmail.com> wrote:\n>>\n>> From: Yury Norov <ynorov@nvidia.com>\n>>\n>> git send-email accepts either revisions or paths to patch files, but its\n>> Bash completion only offers revisions. This prevents patch files from\n>> being completed. It can also make a prefix such as \"0\" expand to an\n>> unrelated hexadecimal ref even when matching 0001-*.patch files exist.\n>>\n>> In my Linux tree, an attempt to autocomplete the standard-named patch\n>> brings a random hashtag:\n>\n> It is unusual to call this a \"hashtag.\" Perhaps \"hash\" or \"object\n> name\" (or id) based on the glossary and datamodel docs?\n\nVery good point, but I am not sure if the author truly meant object\nnames here.  The reproduction test uses a long hexadecimal string,\nbut that is not an object name; it is an unusual-looking tag name.\nIt is like naming a topic branch '012345' and complaining that:\n\n    $ git send-email 0<TAB>\n\ncompletes the input to the branch name while ignoring the\n0001-changes.patch file.\n\nWhen you have a branch named '0-tolerance-policy' and:\n\n    $ git send-email 0<TAB>\n\ncompletes to that branch name, you would not dream of complaining\nabout the completion.  IOW, I think the complaint is somewhat unfair\nto begin with.\n\nActually, I do not know if the completion script really expands an\nabbreviated object name to a full one.  I tried:\n\n    $ git rev-parse seen^2\n    179eccf0d01729c19a3238905b951b1880aa4ba1\n    $ git checkout master\n    $ . contrib/completion/git-completion.bash\n    $ git send-email 17<TAB>\n\nand waited for some time, but it did not complete to anything.\n\nIn any case, when both a '0001-my-changes.patch' file and a\n'0-tolerance-policy' branch exist in your repository and current\nworking directory, running:\n\n    $ git send-email 0<TAB>\n\nshould offer both as candidates, I thihk.  Since I only ever pass\nfilenames to the command, I personally do not think it is a huge\nloss if the completion script stops looking at refs and sticks to\nfilenames only, but others may have a use for that feature.\n\n"},{"id":"548729","messageId":"al-0ckPhoa-ZPhSi@yury","threadId":"66037","inReplyTo":"xmqqcxwgz2u3.fsf@gitster.g","subject":"Re: [PATCH] completion: complete paths for git send-email","fromName":"Yury Norov","fromEmail":"ynorov@nvidia.com","sentAt":"2026-07-21T18:03:30Z","receivedAt":"2026-07-21T18:03:36Z","isPatch":true,"body":"On Tue, Jul 21, 2026 at 10:09:56AM -0700, Junio C Hamano wrote:\n> \"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n> \n> > On Sun, Jul 19, 2026 at 9:45 AM Yury Norov (NVIDIA)\n> > <yury.norov@gmail.com> wrote:\n> >>\n> >> From: Yury Norov <ynorov@nvidia.com>\n> >>\n> >> git send-email accepts either revisions or paths to patch files, but its\n> >> Bash completion only offers revisions. This prevents patch files from\n> >> being completed. It can also make a prefix such as \"0\" expand to an\n> >> unrelated hexadecimal ref even when matching 0001-*.patch files exist.\n> >>\n> >> In my Linux tree, an attempt to autocomplete the standard-named patch\n> >> brings a random hashtag:\n> >\n> > It is unusual to call this a \"hashtag.\" Perhaps \"hash\" or \"object\n> \n> Very good point, but I am not sure if the author truly meant object\n> names here.   > name\" (or id) based on the glossary and datamodel docs?\n\nI said hashtag because for me it's a hash of the tag:\n\ngit send-email 0<TAB>\ngit send-email 05c69d298c96703741cac9a5cbbf6c53bd55a6e2\n\nBut also it's a name of the tag, and git warns about it:\n\n  $ git show 05c69d298c96703741cac9a5cbbf6c53bd55a6e2\n  warning: refname '05c69d298c96703741cac9a5cbbf6c53bd55a6e2' is ambiguous.\n  Git normally never creates a ref that ends with 40 hex characters\n  because it will be ignored when you just specify 40-hex. These refs\n  may be created by mistake. For example,\n  \n    git switch -c $br $(git rev-parse ...)\n  \n  where \"$br\" is somehow empty and a 40-hex ref is created. Please\n  examine these refs and maybe delete them. Turn this message off by\n  running \"git config set advice.objectNameWarning false\"\n  commit 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 (tag: 05c69d298c96703741cac9a5cbbf6c53bd55a6e2)\n  Author: Tejun Heo <tj@kernel.org>\n  Date:   Tue May 15 08:22:04 2012 +0200\n  ...\n\nI have no local branch or local file with that name, but the tag exists\nfor 14 years, and will not go away. And yes, it breaks autocompletion.\n\nSo, after rethinking, the problem looks like this: if autocompletion\nlogic finds a tag beginning with that pattern, it doesn't attempt to\nsearch for the matching files, which is wrong\n\n> The reproduction test uses a long hexadecimal string,\n> but that is not an object name; it is an unusual-looking tag name.\n> It is like naming a topic branch '012345' and complaining that:\n> \n>     $ git send-email 0<TAB>\n> \n> completes the input to the branch name while ignoring the\n> 0001-changes.patch file.\n> \n> When you have a branch named '0-tolerance-policy' and:\n> \n>     $ git send-email 0<TAB>\n> \n> completes to that branch name, you would not dream of complaining\n> about the completion.  IOW, I think the complaint is somewhat unfair\n> to begin with.\n> \n> Actually, I do not know if the completion script really expands an\n> abbreviated object name to a full one.  I tried:\n> \n>     $ git rev-parse seen^2\n>     179eccf0d01729c19a3238905b951b1880aa4ba1\n>     $ git checkout master\n>     $ . contrib/completion/git-completion.bash\n>     $ git send-email 17<TAB>\n> \n> and waited for some time, but it did not complete to anything.\n> \n> In any case, when both a '0001-my-changes.patch' file and a\n> '0-tolerance-policy' branch exist in your repository and current\n> working directory, running:\n> \n>     $ git send-email 0<TAB>\n> \n> should offer both as candidates, I thihk.  Since I only ever pass\n> filenames to the command, I personally do not think it is a huge\n> loss if the completion script stops looking at refs and sticks to\n> filenames only, but others may have a use for that feature.\n\nAgree. The test should create a file 0001.patch, then a tag\n0-tag, then a branch 0-branch, maybe something else that is\nrelevant; and then make sure every option is correctly offered\nby autocompletion.\n\nGuys please let me know if everything else is needed before I send v2.\n\nThanks,\nYury\n"},{"id":"548733","messageId":"xmqqqzkww3ky.fsf@gitster.g","threadId":"66037","inReplyTo":"al-0ckPhoa-ZPhSi@yury","subject":"Re: [PATCH] completion: complete paths for git send-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-21T19:22:05Z","receivedAt":"2026-07-21T19:22:08Z","isPatch":true,"body":"Yury Norov <ynorov@nvidia.com> writes:\n\n>> In any case, when both a '0001-my-changes.patch' file and a\n>> '0-tolerance-policy' branch exist in your repository and current\n>> working directory, running:\n>> \n>>     $ git send-email 0<TAB>\n>> \n>> should offer both as candidates, I thihk.  Since I only ever pass\n>> filenames to the command, I personally do not think it is a huge\n>> loss if the completion script stops looking at refs and sticks to\n>> filenames only, but others may have a use for that feature.\n>\n> Agree. The test should create a file 0001.patch, then a tag\n> 0-tag, then a branch 0-branch, maybe something else that is\n> relevant; and then make sure every option is correctly offered\n> by autocompletion.\n>\n> Guys please let me know if everything else is needed before I send v2.\n\nSo in short, we want the problem description updated to something\nlike:\n\n   When branches and tags whose names share the same prefix as a\n   file (or a directory???) that stores a patch exist, the attempt\n   to complete that shared prefix\n\n       $ git send-email that-shared-prefix<TAB>\n\n   should offer both branches, tags, and files (and directories???).\n   But the completion only offers branches and tags and fails to\n   offer files.\n\nAnd the description of the solution would follow after that in the\nproposed log message.\n\nAs to the tests, using 40-hex is misleading, and 0-branch as you\nsaid would be sufficient to reproduce and demonstrate the issue, and\nthat your code change fixes it.\n\nBen, anything I missed?\n\nThanks.\n\n"},{"id":"548748","messageId":"al/w2qgBfhe9qMg6@szeder.dev","threadId":"66037","inReplyTo":"xmqqcxwgz2u3.fsf@gitster.g","subject":"Re: [PATCH] completion: complete paths for git send-email","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2026-07-21T22:21:14Z","receivedAt":"2026-07-21T22:21:20Z","isPatch":true,"body":"On Tue, Jul 21, 2026 at 10:09:56AM -0700, Junio C Hamano wrote:\n> \"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n> \n> > On Sun, Jul 19, 2026 at 9:45 AM Yury Norov (NVIDIA)\n> > <yury.norov@gmail.com> wrote:\n> >>\n> >> From: Yury Norov <ynorov@nvidia.com>\n> >>\n> >> git send-email accepts either revisions or paths to patch files, but its\n> >> Bash completion only offers revisions. This prevents patch files from\n> >> being completed. It can also make a prefix such as \"0\" expand to an\n> >> unrelated hexadecimal ref even when matching 0001-*.patch files exist.\n> >>\n> >> In my Linux tree, an attempt to autocomplete the standard-named patch\n> >> brings a random hashtag:\n> >\n> > It is unusual to call this a \"hashtag.\" Perhaps \"hash\" or \"object\n> > name\" (or id) based on the glossary and datamodel docs?\n> \n> Very good point, but I am not sure if the author truly meant object\n> names here.  The reproduction test uses a long hexadecimal string,\n> but that is not an object name; it is an unusual-looking tag name.\n> It is like naming a topic branch '012345' and complaining that:\n> \n>     $ git send-email 0<TAB>\n> \n> completes the input to the branch name while ignoring the\n> 0001-changes.patch file.\n> \n> When you have a branch named '0-tolerance-policy' and:\n> \n>     $ git send-email 0<TAB>\n> \n> completes to that branch name, you would not dream of complaining\n> about the completion.  IOW, I think the complaint is somewhat unfair\n> to begin with.\n> \n> Actually, I do not know if the completion script really expands an\n> abbreviated object name to a full one.  I tried:\n> \n>     $ git rev-parse seen^2\n>     179eccf0d01729c19a3238905b951b1880aa4ba1\n>     $ git checkout master\n>     $ . contrib/completion/git-completion.bash\n>     $ git send-email 17<TAB>\n> \n> and waited for some time, but it did not complete to anything.\n\nWe definietely don't do that.  I'm not sure what the use-case would be\nfor completing full object names, but considering how many objects a\nrepo might contain, I doubt it can be usable for anything.\n\n> In any case, when both a '0001-my-changes.patch' file and a\n> '0-tolerance-policy' branch exist in your repository and current\n> working directory, running:\n> \n>     $ git send-email 0<TAB>\n> \n> should offer both as candidates, I thihk.  Since I only ever pass\n> filenames to the command, I personally do not think it is a huge\n> loss if the completion script stops looking at refs and sticks to\n> filenames only, but others may have a use for that feature.\n\nThere are a couple of similar Git commands that accept both refs and\npaths, \"diff\" and \"log\" being the obvious examples, and our completion\nscript doesn't list refs and paths for any of them, only refs [1].\n\nI think that's intentional, because:\n\n  - It's easier to pick the ref you want from a list containing only\n    refs than from a list of refs and paths mixed together, because\n    the list to choose from is shorter, and the unique prefix is\n    likely shorter as well.\n    The same goes for picking the path you want from a list containing\n    only paths.\n\n  - Even when our completion script only lists refs for a particular\n    command, it's easy to trigger Bash's filename completion via one\n    of the following methods:\n\n      - git diff ./foo<TAB>  # No ref can start with \"./\".\n      - git log foo<ALT-/>   # Bash/readline's keybinding to trigger\n                             # filename completion.\n      - git log -- foo<TAB>  # No --options or refs after the\n                             # disambiguating doubledash.\n\n    Although I'm not sure \"git send-email\" supports the disambiguating\n    doubledash; its completion function surely doesn't.\n\n  - There is no similarly easy way to trigger refs completion.\n\n[1] There are a couple of (sub)commands, like \"git worktree add\" or\n    \"git bungle create\", where our completion script lists either\n    paths or refs (but never both) depending on what's already on the\n    command line.  But both of these expect a single path followed by\n    a single ref or any revision arguments, so we can unambigously\n    figure out when to list paths and when to list refs.  With \"diff\",\n    \"log\" and \"send-email\" this is not possible, because they accept\n    any revision arguments followed by paths.\n\n"},{"id":"548770","messageId":"C9564DC6-6B68-46CA-A339-1A1774AFA7C0@gmail.com","threadId":"66037","inReplyTo":"xmqqqzkww3ky.fsf@gitster.g","subject":"Re: [PATCH] completion: complete paths for git send-email","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-07-22T10:29:43Z","receivedAt":"2026-07-22T10:29:57Z","isPatch":true,"body":"\n> Le 21 juil. 2026 à 15:22, Junio C Hamano <gitster@pobox.com> a écrit :\n> \n> Yury Norov <ynorov@nvidia.com> writes:\n> \n>>> In any case, when both a '0001-my-changes.patch' file and a\n>>> '0-tolerance-policy' branch exist in your repository and current\n>>> working directory, running:\n>>>   $ git send-email 0<TAB>\n>>> should offer both as candidates, I thihk.  Since I only ever pass\n>>> filenames to the command, I personally do not think it is a huge\n>>> loss if the completion script stops looking at refs and sticks to\n>>> filenames only, but others may have a use for that feature.\n>> Agree. The test should create a file 0001.patch, then a tag\n>> 0-tag, then a branch 0-branch, maybe something else that is\n>> relevant; and then make sure every option is correctly offered\n>> by autocompletion.\n>> Guys please let me know if everything else is needed before I send v2.\n> \n> So in short, we want the problem description updated to something\n> like:\n> \n>  When branches and tags whose names share the same prefix as a\n>  file (or a directory???) that stores a patch exist, the attempt\n>  to complete that shared prefix\n> \n>      $ git send-email that-shared-prefix<TAB>\n> \n>  should offer both branches, tags, and files (and directories???).\n>  But the completion only offers branches and tags and fails to\n>  offer files.\n> \n> And the description of the solution would follow after that in the\n> proposed log message.\n> \n> As to the tests, using 40-hex is misleading, and 0-branch as you\n> said would be sufficient to reproduce and demonstrate the issue, and\n> that your code change fixes it.\n> \n> Ben, anything I missed?\n> \n> Thanks.\n\nNot from my end, though SZEDER’s review merits some thinking.\n\nTraveling the next week+; replies may be slower (than usual, hah)."},{"id":"548783","messageId":"xmqq4ihrt4yt.fsf@gitster.g","threadId":"66037","inReplyTo":"C9564DC6-6B68-46CA-A339-1A1774AFA7C0@gmail.com","subject":"Re: [PATCH] completion: complete paths for git send-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-22T15:32:42Z","receivedAt":"2026-07-22T15:32:45Z","isPatch":true,"body":"Ben Knoble <ben.knoble@gmail.com> writes:\n\n>> As to the tests, using 40-hex is misleading, and 0-branch as you\n>> said would be sufficient to reproduce and demonstrate the issue, and\n>> that your code change fixes it.\n>> \n>> Ben, anything I missed?\n>> \n>> Thanks.\n>\n> Not from my end, though SZEDER’s review merits some thinking.\n\nI agree that presenting both refs and paths cleanly will require a\nmuch better structure than a flat list.  I also agree that hiding\npaths when we have ref matches may give us a cleaner layout than\nmixing them alphabetically into a single, flat list.  While I am\nstill not convinced it is the best way, at least that is the\nprinciple current completion implementations use for other commands,\nand it makes sense to model the updated completion for send-email\nafter it.\n\nThat said, since I never feed refs to send-email myself, 'if we have\nmatches with refs, do not show paths at all' rule makes send-email\ncompletion completely useless, at least to me.\n\n> Traveling the next week+; replies may be slower (than usual, hah).\n\nHave a great trip, and have fun!\n\nThanks.\n"}]}