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

> Denton Liu <liu.denton@gmail.com> 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?