Re: Error in bash completion

From: Harrison McCullough <mccullough.harrison@gmail.com>
Date: Jun 16, 2021, 18:05 UTC
Message-ID: <CAHLeu+xC+ecEidoofXsOqSdT4fmf=5A1PAnHzbFPqCiPr5D+BA@mail.gmail.com>
In-Reply-To: <YMo3j6mqiKBTTEbS@generichostname>

I don't have any knowledge of the expectations regarding Git internals, but I think it would be good to note that lines 32-33 of `git-completion.bash` say this:

    If you have a command that is not part of git, but you would still
    like completion, you can use __git_complete:

For me that would imply that the `__git_complete` function is intended to be a "public interface", but maybe I'm reading it wrong.

-Harrison McCullough

On Wed, Jun 16, 2021 at 11:40 AM Denton Liu <liu.denton@gmail.com> wrote:

Show 40 quoted lines

>
> Hi Harrison,
>
> On Wed, Jun 16, 2021 at 09:44:38AM -0600, Harrison McCullough wrote:
> > What did you do before the bug happened? (Steps to reproduce your issue)
> >
> > 1. Create a Bash function, e.g. `ga() { git add "${@:-.}"; }`
> > 2. Use the `__git_complete` function to add Bash tab completion for your custom
> >    Bash function, e.g. `__git_complete ga git_add`
> > 3. Attempt to tab complete a file path, e.g. `ga my-incomplete-file-path<TAB>`
> >
> >
> > What did you expect to happen? (Expected behavior)
> >
> > Bash tab-completes the file path.
> >
> >
> > What happened instead? (Actual behavior)
> >
> > Bash tab-completes the file path but also displays an error:
> >
> > $ ga fi-bash: [: -lt: unary operator expected
> > le3.txt
>
> This happened as a result of my changes at e94fb44042
> (git-completion.bash: pass $__git_subcommand_idx from __git_main(),
> 2021-03-24) and 87e629756f (git-completion.bash: rename to
> $__git_cmd_idx, 2021-04-22).
>
> The tl;dr is that $__git_cmd_idx must be set to the index of the
> git command you're executing (e.g. for `git add`, the index of `add`).
> As a workaround for you, try setting __git_cmd_idx=0 where you define
> ga().
>
> Now, a question to the wider list: does git-completion.bash have a
> public interface? I've been working off the assumption that any time a
> user uses the internals, it's at their own risk. Is this a valid
> assumption to make?
>
> -Denton