From: Junio C Hamano <gitster@pobox.com>
To: "David Cantrell via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, David Cantrell <david@cantrell.org.uk>
Subject: Re: [PATCH] tab completion of filenames for 'git restore'
Date: Sat, 12 Mar 2022 22:45:36 -0800 [thread overview]
Message-ID: <xmqqlexel59r.fsf@gitster.g> (raw)
In-Reply-To: <pull.1227.git.git.1647032857097.gitgitgadget@gmail.com> (David Cantrell via GitGitGadget's message of "Fri, 11 Mar 2022 21:07:36 +0000")
"David Cantrell via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: David Cantrell <david@cantrell.org.uk>
>
> If no --args are present after 'git restore' it assumes that you want
> to tab-complete one of the files with uncommitted changes
>
> Signed-off-by: David Cantrell <david@cantrell.org.uk>
> ---
> 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?
- 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.
Modelling it after "git add" completion, where we look for paths
that are different between the index and the working tree, feels
more appropriate, but I haven't thought things through.
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1227%2FDrHyde%2Ffilename-completion-for-git-restore-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1227/DrHyde/filename-completion-for-git-restore-v1
> Pull-Request: https://github.com/git/git/pull/1227
>
> contrib/completion/git-completion.bash | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 49a328aa8a4..7ccad8ff4b1 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -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
> ;;
> --*)
> __gitcomp_builtin restore
> + return
> ;;
> esac
> +
> + if __git rev-parse --verify --quiet HEAD >/dev/null; then
> + __git_complete_index_file "--committable"
> + fi
> }
Do you need to sprinkle return's? Instead you could just add
another case arm, like
case "$cur" in
--conflict=*)
... all the existing code ...
--*)
__gitcomp_builtin restore
;;
+ *)
+ ... whatever you want to do when
+ ... $cur is not a --dashed-option
+ ;;
esac
next prev parent reply other threads:[~2022-03-13 6:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 21:07 [PATCH] tab completion of filenames for 'git restore' David Cantrell via GitGitGadget
2022-03-13 6:45 ` Junio C Hamano [this message]
2022-03-14 23:45 ` David Cantrell
2022-03-15 10:23 ` Junio C Hamano
2022-03-15 0:52 ` [PATCH v2 0/2] Improved bash tab completion for 'git restore' - adds support for auto-completing filenames David Cantrell via GitGitGadget
2022-03-15 0:52 ` [PATCH v2 1/2] tab completion of filenames for 'git restore' David Cantrell via GitGitGadget
2022-03-15 0:52 ` [PATCH v2 2/2] if a file has been staged we don't want to list it David Cantrell via GitGitGadget
2022-03-16 11:45 ` Bagas Sanjaya
2022-03-15 11:23 ` [PATCH v2 0/2] Improved bash tab completion for 'git restore' - adds support for auto-completing filenames Junio C Hamano
2022-03-15 16:27 ` Junio C Hamano
2022-03-15 22:13 ` [PATCH v3] tab completion of filenames for 'git restore' David Cantrell via GitGitGadget
2022-03-16 0:44 ` Junio C Hamano
2022-03-17 22:16 ` David Cantrell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqlexel59r.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=david@cantrell.org.uk \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).