[v3] tab completion of filenames for 'git restore'

Commit Message

David Cantrell March 15, 2022, 10:13 p.m. UTC

From: David Cantrell <[e-mail]>

If no --args are present after 'git restore' it assumes that you want
to tab-complete one of the files with unstaged uncommitted changes.

If a file has been staged we don't want to list it, as restoring those
requires a slightly more complex `git restore --staged`, so we only list
those files that are --modified. While --committable also looks like
a good candidate, that includes changes that have been staged.

Signed-off-by: David Cantrell <[e-mail]>
---
    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.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1227%2FDrHyde%2Ffilename-completion-for-git-restore-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1227/DrHyde/filename-completion-for-git-restore-v3
Pull-Request: https://github.com/git/git/pull/1227

Range-diff vs v2:

 1:  2bb8f1cb1c4 ! 1:  779744b9fc5 tab completion of filenames for 'git restore'
     @@ Commit message
          tab completion of filenames for 'git restore'
      
          If no --args are present after 'git restore' it assumes that you want
     -    to tab-complete one of the files with uncommitted changes
     +    to tab-complete one of the files with unstaged uncommitted changes.
     +
     +    If a file has been staged we don't want to list it, as restoring those
     +    requires a slightly more complex `git restore --staged`, so we only list
     +    those files that are --modified. While --committable also looks like
     +    a good candidate, that includes changes that have been staged.
      
          Signed-off-by: David Cantrell <[e-mail]>
      
       ## contrib/completion/git-completion.bash ##
      @@ contrib/completion/git-completion.bash: _git_restore ()
     - 	case "$cur" in
     - 	--conflict=*)
     - 		__gitcomp "diff3 merge zdiff3" "" "${cur##--conflict=}"
     -+		return
     - 		;;
     - 	--source=*)
     - 		__git_complete_refs --cur="${cur##--source=}"
     -+		return
     - 		;;
       	--*)
       		__gitcomp_builtin restore
     -+		return
       		;;
     ++	*)
     ++		if __git rev-parse --verify --quiet HEAD >/dev/null; then
     ++			__git_complete_index_file "--modified"
     ++		fi
       	esac
     -+
     -+	if __git rev-parse --verify --quiet HEAD >/dev/null; then
     -+		__git_complete_index_file "--committable"
     -+	fi
       }
       
     - __git_revert_inprogress_options=$__git_sequencer_inprogress_options
 2:  16aa4d0b2e4 < -:  ----------- if a file has been staged we don't want to list it


 contrib/completion/git-completion.bash | 4 ++++
 1 file changed, 4 insertions(+)


base-commit: 1a4874565fa3b6668042216189551b98b4dc0b1b

Comments

Junio C Hamano March 16, 2022, 12:44 a.m. UTC | #1

"David Cantrell via GitGitGadget" <[e-mail]> writes:

> From: David Cantrell <[e-mail]>
> Subject: Re: [PATCH v3] tab completion of filenames for 'git restore'

Perhaps

    Subject: [PATCH v3] completion: complete modified files for 'git restore'

cf. Documentation/SubmittingPatches::[[summary-section]]


> If no --args are present after 'git restore' it assumes that you want
> to tab-complete one of the files with unstaged uncommitted changes.

Since it is our convention that the first paragraph talks about the
current behaviour, i.e. without the proposed changes applied, in the
present tense, I'd assume the above is what the current code does.

What do you mean by "--args" in this sentence?  Dashed-options?
I am getting the same set of files whose name begins with 'a' from
these two:

 $ git restore a<TAB>
 $ git restore --staged a<TAB>

so, with or without --dashed-options, we complete one of the files,
whether they have any modifications.

Perhaps you meant to say more like:

    When completing a non-option argument to 'git restore', the
    command line completion support offers names of the files
    present in the working tree as candidates.

to describe the status quo; to hint what the shortcoming of the
current behaviour is, we may want to add a bit more, perhaps
append the following at the end of that first paragraph:

    But many of these files may not have any changes, and running
    "restore" on them would be a no-op.  Listing only the files, to
    which doing "restore" is not a no-op, would reduce the clutter.
    
Then we'd continue with the solution, while explaining why the exact
choice between modified vs committable was made:

    Offer only the files that are different from the index, to match
    the default behaviour of "git restore" that checks out the
    contents last added to the index to the working tree.  We could
    instead show the files that are different between the index and
    HEAD, and that is more suittable if "git restore --staged" is
    being completed, but this should do for now.

or something.  The last part is written in such a way to explicitly
signal to future developers that we know we did not do a perfect job
and we do not mind if they extend the logic to use something other
than "--modified" when appropriate.  For example, they could build
on this solution to make it inspect the command line for "--staged"
and "--source" and drive "diff-index" differently to grab the paths
that are offered.  We just do not do that at least for now, but we
have no objection if other people do so in the future.

Thanks.  Will queue as-is for now.

> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 49a328aa8a4..ba5c395d2d8 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2890,6 +2890,10 @@ _git_restore ()
>  	--*)
>  		__gitcomp_builtin restore
>  		;;
> +	*)
> +		if __git rev-parse --verify --quiet HEAD >/dev/null; then
> +			__git_complete_index_file "--modified"
> +		fi
>  	esac
>  }
>  
>
> base-commit: 1a4874565fa3b6668042216189551b98b4dc0b1b

David Cantrell March 17, 2022, 10:16 p.m. UTC | #2

On 16/03/2022 00:44, Junio C Hamano wrote:
> "David Cantrell via GitGitGadget" <[e-mail]> writes:
>> If no --args are present after 'git restore' it assumes that you want
>> to tab-complete one of the files with unstaged uncommitted changes.
> What do you mean by "--args" in this sentence?  Dashed-options?

Yes.

> I am getting the same set of files whose name begins with 'a' from
> these two:
> 
>   $ git restore a<TAB>
>   $ git restore --staged a<TAB>
> 
> so, with or without --dashed-options, we complete one of the files,
> whether they have any modifications.

If --staged is present I think it falls back to the standard behaviour 
of attempting to complete to any file it can find

> Perhaps you meant to say more like:
> 
>      When completing a non-option argument to 'git restore', the
>      command line completion support offers names of the files
>      present in the working tree as candidates.
> 
> to describe the status quo; to hint what the shortcoming of the
> current behaviour is, we may want to add a bit more, perhaps
> append the following at the end of that first paragraph:
> 
>      But many of these files may not have any changes, and running
>      "restore" on them would be a no-op.  Listing only the files, to
>      which doing "restore" is not a no-op, would reduce the clutter.
>      
> Then we'd continue with the solution, while explaining why the exact
> choice between modified vs committable was made:
> 
>      Offer only the files that are different from the index, to match
>      the default behaviour of "git restore" that checks out the
>      contents last added to the index to the working tree.  We could
>      instead show the files that are different between the index and
>      HEAD, and that is more suittable if "git restore --staged" is
>      being completed, but this should do for now.
> 
> or something.  The last part is written in such a way to explicitly
> signal to future developers that we know we did not do a perfect job
> and we do not mind if they extend the logic to use something other
> than "--modified" when appropriate.  For example, they could build
> on this solution to make it inspect the command line for "--staged"
> and "--source" and drive "diff-index" differently to grab the paths
> that are offered.  We just do not do that at least for now, but we
> have no objection if other people do so in the future.

That makes sense.

> Thanks.  Will queue as-is for now.

Thank you.

Patch

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 49a328aa8a4..ba5c395d2d8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2890,6 +2890,10 @@  _git_restore ()
 	--*)
 		__gitcomp_builtin restore
 		;;
+	*)
+		if __git rev-parse --verify --quiet HEAD >/dev/null; then
+			__git_complete_index_file "--modified"
+		fi
 	esac
 }