Strange behavior about option completion of `git push`

Strange behavior about option completion of `git push`

[Yasuhiro KIMURA]

Hello,

I use zsh 5.8 on some OSes (CentOS, Cygwin, Debian, FreeBSD, etc.) and
found strange behavior about option completion of `git push`.

At first let's type `git push --r` and hit TAB. Then it is completed
as `git push --re`. Options of `git push` that start with `--r` are
`--receive-pack`, `--recurse-submodules` and `--repo` and all of them
start with `--re`. So it is reasonable that completion works as above.

Next let's type `git push --f' and hit TAB. In this case options that
start with `--f' are `--follow-tags`, `--force` and
`--force-with-lease` and all of them start with `--fo`. So expected
behavior is that it will be completed as `git push --fo`. But what
really happens is that there is no change after TAB is hit.

I checked definition of `_git-push` function in
/usr/share/zsh/5.8/functions/Completion/Unix/_git but didn't find the
source of the difference.

Would someone please explain why such differnce happens?

Best Regards.

---
Yasuhiro KIMURA

Re: Strange behavior about option completion of `git push`

[Bart Schaefer]

On Thu, Sep 17, 2020 at 10:24 AM Yasuhiro KIMURA <yasu@utahime.org> wrote:
>
> At first let's type `git push --r` and hit TAB. Then it is completed
> as `git push --re`.
>
> Next let's type `git push --f' and hit TAB. In this case ... expected
> behavior is that it will be completed as `git push --fo`. But what
> really happens is that there is no change after TAB is hit.
>
> Would someone please explain why such differnce happens?

I think the difference is that --force-with-lease has a required
argument, which differs from the other two --f options, whereas none
of the --r completions has an argument.

However, without a lot of digging, I don't know why that affects the
position of the first perceived ambiguity.

Re: Strange behavior about option completion of `git push`

[Oliver Kiddle]

Yasuhiro KIMURA wrote:
> Next let's type `git push --f' and hit TAB. In this case options that
> start with `--f' are `--follow-tags`, `--force` and
> `--force-with-lease` and all of them start with `--fo`. So expected
> behavior is that it will be completed as `git push --fo`. But what
> really happens is that there is no change after TAB is hit.

This appears to be a bug in the zsh completion internals. The difference
between --f and --r is that for --f, the options are added with more
than one call to compadd because there's a mix of suffix characters
required on those options.

Any further discussion on this line should probably go to -workers but a
minimal function to reproduce the issue is as follows:

  compadd -M 'r:|.=*' one
  compadd -M 'r:|-=*' - --follow-tags --force
  compadd -M 'r:|-=*' - --force-with-lease
  return 0

With _git_push the first of these compadd calls is from _ssh_hosts. The
matching control options are needed. The latter two with - as a pivot
but the first can use any character. The case with --r is equivalent to
combining the latter two compadd calls into a single call.

Matching control is known to have some gnarly issues.

Oliver

Re: Strange behavior about option completion of `git push`

[Yasuhiro KIMURA]

From: Bart Schaefer <schaefer@brasslantern.com>
Subject: Re: Strange behavior about option completion of `git push`
Date: Thu, 17 Sep 2020 11:05:43 -0700

> I think the difference is that --force-with-lease has a required
> argument, which differs from the other two --f options, whereas none
> of the --r completions has an argument.

Oh, I didn't notice it.

From: Oliver Kiddle <opk@zsh.org>
Subject: Re: Strange behavior about option completion of `git push`
Date: Thu, 17 Sep 2020 21:36:19 +0200

> This appears to be a bug in the zsh completion internals. The difference
> between --f and --r is that for --f, the options are added with more
> than one call to compadd because there's a mix of suffix characters
> required on those options.
> 
> Any further discussion on this line should probably go to -workers but a
> minimal function to reproduce the issue is as follows:
> 
>   compadd -M 'r:|.=*' one
>   compadd -M 'r:|-=*' - --follow-tags --force
>   compadd -M 'r:|-=*' - --force-with-lease
>   return 0
> 
> With _git_push the first of these compadd calls is from _ssh_hosts. The
> matching control options are needed. The latter two with - as a pivot
> but the first can use any character. The case with --r is equivalent to
> combining the latter two compadd calls into a single call.
> 
> Matching control is known to have some gnarly issues.

It seems too much for me to handle this issue. So I would like to
leave the investigation of it to someone familiar with the internals
of zsh completion.

---
Yasuhiro KIMURA