Re: [PATCH] completion: complete paths for git send-email

[Yury Norov <ynorov@nvidia.com>]

On Tue, Jul 21, 2026 at 10:09:56AM -0700, Junio C Hamano wrote:
> "D. Ben Knoble" <ben.knoble@gmail.com> writes:
> 
> > On Sun, Jul 19, 2026 at 9:45 AM Yury Norov (NVIDIA)
> > <yury.norov@gmail.com> wrote:
> >>
> >> From: Yury Norov <ynorov@nvidia.com>
> >>
> >> git send-email accepts either revisions or paths to patch files, but its
> >> Bash completion only offers revisions. This prevents patch files from
> >> being completed. It can also make a prefix such as "0" expand to an
> >> unrelated hexadecimal ref even when matching 0001-*.patch files exist.
> >>
> >> In my Linux tree, an attempt to autocomplete the standard-named patch
> >> brings a random hashtag:
> >
> > It is unusual to call this a "hashtag." Perhaps "hash" or "object
> 
> Very good point, but I am not sure if the author truly meant object
> names here.   > name" (or id) based on the glossary and datamodel docs?

I said hashtag because for me it's a hash of the tag:

git send-email 0<TAB>
git send-email 05c69d298c96703741cac9a5cbbf6c53bd55a6e2

But also it's a name of the tag, and git warns about it:

  $ git show 05c69d298c96703741cac9a5cbbf6c53bd55a6e2
  warning: refname '05c69d298c96703741cac9a5cbbf6c53bd55a6e2' is ambiguous.
  Git normally never creates a ref that ends with 40 hex characters
  because it will be ignored when you just specify 40-hex. These refs
  may be created by mistake. For example,
  
    git switch -c $br $(git rev-parse ...)
  
  where "$br" is somehow empty and a 40-hex ref is created. Please
  examine these refs and maybe delete them. Turn this message off by
  running "git config set advice.objectNameWarning false"
  commit 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 (tag: 05c69d298c96703741cac9a5cbbf6c53bd55a6e2)
  Author: Tejun Heo <tj@kernel.org>
  Date:   Tue May 15 08:22:04 2012 +0200
  ...

I have no local branch or local file with that name, but the tag exists
for 14 years, and will not go away. And yes, it breaks autocompletion.

So, after rethinking, the problem looks like this: if autocompletion
logic finds a tag beginning with that pattern, it doesn't attempt to
search for the matching files, which is wrong

> The reproduction test uses a long hexadecimal string,
> but that is not an object name; it is an unusual-looking tag name.
> It is like naming a topic branch '012345' and complaining that:
> 
>     $ git send-email 0<TAB>
> 
> completes the input to the branch name while ignoring the
> 0001-changes.patch file.
> 
> When you have a branch named '0-tolerance-policy' and:
> 
>     $ git send-email 0<TAB>
> 
> completes to that branch name, you would not dream of complaining
> about the completion.  IOW, I think the complaint is somewhat unfair
> to begin with.
> 
> Actually, I do not know if the completion script really expands an
> abbreviated object name to a full one.  I tried:
> 
>     $ git rev-parse seen^2
>     179eccf0d01729c19a3238905b951b1880aa4ba1
>     $ git checkout master
>     $ . contrib/completion/git-completion.bash
>     $ git send-email 17<TAB>
> 
> and waited for some time, but it did not complete to anything.
> 
> In any case, when both a '0001-my-changes.patch' file and a
> '0-tolerance-policy' branch exist in your repository and current
> working directory, running:
> 
>     $ git send-email 0<TAB>
> 
> should offer both as candidates, I thihk.  Since I only ever pass
> filenames to the command, I personally do not think it is a huge
> loss if the completion script stops looking at refs and sticks to
> filenames only, but others may have a use for that feature.

Agree. The test should create a file 0001.patch, then a tag
0-tag, then a branch 0-branch, maybe something else that is
relevant; and then make sure every option is correctly offered
by autocompletion.

Guys please let me know if everything else is needed before I send v2.

Thanks,
Yury