Re: [PATCH 3/4] completion: reflog with implicit "show"

[Junio C Hamano <gitster@pobox.com>]

Rubén Justo <rjusto@gmail.com> writes:

>> So, when we see something that could be a subcommand we complete it
>> as a subcommand and return.  In your example, how should
>> 
>>     $ git reflog def<TAB>
>> 
>> work?  We try to see if there is a subcommand that begins with
>> "def", we see nothing matching, and then run __git_complete_refs?
>> What if the branch you created earlier were not named "default" but,
>> say, "delmonte", and you did "git reflog del<TAB>"?  Shouldn't the
>> user be offered "delete" and "delmonte" as potential completions?
>> 
>> >  __git_send_email_confirm_options="always never auto cc compose"
>> > diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
>> > index aa9a614de3..231e17f378 100755
>> > --- a/t/t9902-completion.sh
>> > +++ b/t/t9902-completion.sh
>> > @@ -2618,6 +2618,14 @@ test_expect_success 'git clone --config= - value' '
>> >  	EOF
>> >  '
>> >  
>> > +test_expect_success 'git reflog show' '
>> > +	test_when_finished "git checkout -" &&
>> > +	git checkout -b shown &&
>> > +	test_completion "git reflog sho" "show " &&
>> 
>> IOW, shouldn't this offer both show and shown?
>
> What should we do?

I would imagine that we should make the above offer both "show"
(because it can be what the user meant) and "shown" (because it can
also be what the user meant)?  But thinking of it again, because
"show" is a prefix of "shown", this should offer "show" and then
another <TAB> would offer "show" and "shown".  At least, that is
what I would expect from the usual bash completion behaviour, which
would look like:

    $ mkdir /var/tmp/scratch && cd /var/tmp/scratch
    $ : >show 2>shown
    $ echo sho<TAB>

The <TAB> makes the above line expand to

    $ echo show

and place the curser immediately after 'w' (without a space after it).
Giving another <TAB> at this point offers two possible candidates.

    $ echo show<TAB>
    show shown

So, I'd expect a similar completion to happen, i.e.

    $ git reflog sho<TAB>
-->
    $ git reflog show

because there are two candidates, "show" and "shown", and I can type
another <TAB> at that point to see the two candidates.

    $ git reflog show<TAB>
    show shown

If the branch name were "shot" instead of "shown", then the possible
choices would become "show" and "shot", so we'd skip one step from
the above and immediately get the two candidates against "sho<TAB>".

    $ git reflog sho<TAB>
    shot show

That is what I would expect.    

Thanks.