Re: [RESEND PATCH 2/3] git-completion.bash: fix `git <args>... stash branch` bug

Denton Liu [off-list ref] writes:

When completions are offered for `git stash branch<TAB>`, the user is
supposed to receive refs. This works in the case where the main git
command is called without arguments but if options are provided, such as
`git -C dir stash branch<TAB>`, then the `$cword -eq 3` provides
incorrect results.

Count the words relative to the first instance of "stash" so that we
ignore arguments to the main git command.

Unfortunately, this still does not work 100% correctly. For example, in
the case of something like `git -C stash stash branch<TAB>`, this will
incorrectly identify the first "stash" as the command. This seems to be
an edge-case that we can ignore, though, as other functions, such as
_git_worktree(), suffer from the same problem.

I am not familiar with how the completion support works, but doing
this inside _git_stash() and still not being able to tell which
"stash" on the command line is supposed to be the git subcommand
smells quite fishy to me.  

How did the caller decide to invoke _git_stash helper function in
the first place?

When it is given "git -C push --paginate stash branch<TAB>", it must
have parsed the command line, past the options given to the "git"
potty, to find "stash" on the command line that it is _git_stash and
not _git_push that needs to be called, no?  If it were possible to
propagate that information without losing it, then we do not have to
recompute where the subcommand name is at all, do we?

Hi Junio,

On Thu, Mar 18, 2021 at 01:30:38PM -0700, Junio C Hamano wrote:

Denton Liu [off-list ref] writes:

quoted

When completions are offered for `git stash branch<TAB>`, the user is
supposed to receive refs. This works in the case where the main git
command is called without arguments but if options are provided, such as
`git -C dir stash branch<TAB>`, then the `$cword -eq 3` provides
incorrect results.

Count the words relative to the first instance of "stash" so that we
ignore arguments to the main git command.

Unfortunately, this still does not work 100% correctly. For example, in
the case of something like `git -C stash stash branch<TAB>`, this will
incorrectly identify the first "stash" as the command. This seems to be
an edge-case that we can ignore, though, as other functions, such as
_git_worktree(), suffer from the same problem.

I am not familiar with how the completion support works, but doing
this inside _git_stash() and still not being able to tell which
"stash" on the command line is supposed to be the git subcommand
smells quite fishy to me.  

How did the caller decide to invoke _git_stash helper function in
the first place?

When it is given "git -C push --paginate stash branch<TAB>", it must
have parsed the command line, past the options given to the "git"
potty, to find "stash" on the command line that it is _git_stash and
not _git_push that needs to be called, no?  If it were possible to
propagate that information without losing it, then we do not have to
recompute where the subcommand name is at all, do we?

Good observation. _git_stash() is called in the body of
__git_complete_command() which is called by __git_main(). There is
currently no mechanism by which to pass the index of the command over to
_git_*() completion functions.

That being said, passing in the index to all functions would definitely
be doable. I can work on a series in the future that passes in the index
of the command so that working with $cword is more robust but I'd prefer
if that were handled outside this series to keep it focused.

Thanks,
Denton