From: David Cantrell <david@cantrell.org.uk>
Date: Mon, 14 Mar 2022 23:45:33 GMT
Subject: Re: [PATCH] tab completion of filenames for 'git restore'
Message-ID: <2ae04989-156c-63a2-c191-67f97bb6c7b9@cantrell.org.uk>
In-Reply-To: <xmqqlexel59r.fsf@gitster.g>

On 13/03/2022 06:45, Junio C Hamano wrote:
> "David Cantrell via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>      Improved bash tab completion for 'git restore' - adds support for
>>      auto-completing filenames
>>      
>>      This adds tab-completion of filenames to the bash completions for git
>>      restore.
> Two questions
> 
>   - "restore" is a castrated half "checkout"; shouldn't the latter
>     also be getting the same feature?

`git checkout <tab>` already completes to a list of branches and tags, 
which is I think more useful in that case.

>   - is "complete_index_file --committable" the right thing to use?
> 
>     It boils down to running "diff-index HEAD", which means path with
>     differences from the HEAD commit is listed.  By default "restore"
>     checks out the contents of the given path from the index to the
>     working tree, so after "edit F && git add F", "diff-index HEAD"
>     may show F in its output (i.e. F is "committable"), but "restore
>     F" would be a no-op.  Which feels a bit iffy.

I'd not thought of that. --modified is better.

>> @@ -2883,14 +2883,21 @@ _git_restore ()
>>   	case "$cur" in
>>   	--conflict=*)
>>   		__gitcomp "diff3 merge zdiff3" "" "${cur##--conflict=}"
>> +		return
>>   		;;
>>   	--source=*)
>>   		__git_complete_refs --cur="${cur##--source=}"
>> +		return
>>   		;;
>> ...
> Do you need to sprinkle return's?  Instead you could just add
> another case arm, like
> 
> +	*)
> +		... whatever you want to do when
> +		... $cur is not a --dashed-option
> +		;;

Liberal sprinkling of return like that seems to be the norm for the rest 
of the file so I stuck with it.

-- 
David Cantrell