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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 21, 2026, 17:09 UTC
Message-ID: <xmqqcxwgz2u3.fsf@gitster.g>
In-Reply-To: <CALnO6CAuitGp_xLYkXpkQYV9oiXsNNfsXZ_OqzkW7_6ND49=LA@mail.gmail.com>

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

Show 15 quoted lines

> 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
> name" (or id) based on the glossary and datamodel docs?

Very good point, but I am not sure if the author truly meant object names here. 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.