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

[SZEDER Gábor]

On Tue, Jul 21, 2026 at 10:09:56AM -0700, Junio C Hamano wrote:
> "D. Ben Knoble" <ben.knoble@xxxxxxxxx> writes:
> 
> > On Sun, Jul 19, 2026 at 9:45 AM Yury Norov (NVIDIA)
> > <yury.norov@xxxxxxxxx> wrote:
> >>
> >> From: Yury Norov <ynorov@xxxxxxxxxx>
> >>
> >> 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.

We definietely don't do that.  I'm not sure what the use-case would be
for completing full object names, but considering how many objects a
repo might contain, I doubt it can be usable for 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.

There are a couple of similar Git commands that accept both refs and
paths, "diff" and "log" being the obvious examples, and our completion
script doesn't list refs and paths for any of them, only refs [1].

I think that's intentional, because:

  - It's easier to pick the ref you want from a list containing only
    refs than from a list of refs and paths mixed together, because
    the list to choose from is shorter, and the unique prefix is
    likely shorter as well.
    The same goes for picking the path you want from a list containing
    only paths.

  - Even when our completion script only lists refs for a particular
    command, it's easy to trigger Bash's filename completion via one
    of the following methods:

      - git diff ./foo<TAB>  # No ref can start with "./".
      - git log foo<ALT-/>   # Bash/readline's keybinding to trigger
                             # filename completion.
      - git log -- foo<TAB>  # No --options or refs after the
                             # disambiguating doubledash.

    Although I'm not sure "git send-email" supports the disambiguating
    doubledash; its completion function surely doesn't.

  - There is no similarly easy way to trigger refs completion.

[1] There are a couple of (sub)commands, like "git worktree add" or
    "git bungle create", where our completion script lists either
    paths or refs (but never both) depending on what's already on the
    command line.  But both of these expect a single path followed by
    a single ref or any revision arguments, so we can unambigously
    figure out when to list paths and when to list refs.  With "diff",
    "log" and "send-email" this is not possible, because they accept
    any revision arguments followed by paths.