Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

[Cornelius Weig]

On 02/15/2017 03:26 PM, SZEDER Gábor wrote:
> On Tue, Feb 14, 2017 at 10:24 PM,   wrote:
> 
>> +   *)
>> +   __git_complete_tree_file "$ref" "$cur"
>> +   ;;
> 
> There is one more caveat here.
> 
> Both our __git_complete_index_file() and Bash's builtin filename
> completion lists matching paths like this:
> 
>   $ git rm contrib/co
>   coccinelle/contacts/
>   completion/convert-grafts-to-replace-refs.sh
> 
> i.e. the leading path components are not redundantly repeated.
> 
> Now, with this patch in this code path the list would look like this:
> 
>   $ git checkout completion-refs-speedup contrib/co
>   contrib/coccinelle/
>   contrib/completion/
>   contrib/contacts/
>   contrib/convert-grafts-to-replace-refs.sh
> 
> See the difference?

Now that you say it.. I had never noticed it though.

> I once made a feeble attempt to make completion of the :
> notation (i.e. what you extracted into __git_complete_tree_file())
> look like regular filename completion, but couldn't.

Can you dig up what you tried out? Maybe somebody comes up with a good idea.

Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

[SZEDER Gábor]

On Tue, Feb 14, 2017 at 10:24 PM,   wrote:

> +   *)
> +   __git_complete_tree_file "$ref" "$cur"
> +   ;;

There is one more caveat here.

Both our __git_complete_index_file() and Bash's builtin filename
completion lists matching paths like this:

  $ git rm contrib/co
  coccinelle/contacts/
  completion/convert-grafts-to-replace-refs.sh

i.e. the leading path components are not redundantly repeated.

Now, with this patch in this code path the list would look like this:

  $ git checkout completion-refs-speedup contrib/co
  contrib/coccinelle/
  contrib/completion/
  contrib/contacts/
  contrib/convert-grafts-to-replace-refs.sh

See the difference?

I once made a feeble attempt to make completion of the :
notation (i.e. what you extracted into __git_complete_tree_file())
look like regular filename completion, but couldn't.

Gábor

Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

[Cornelius Weig]

Although I'm not convinced that completion of modified files is unnecessary, 
I'm at least persuaded that not all users would welcome such a change. Given 
the hint from Gabor that Alt-/ forces filesystem completion, there is even no 
big win in stopping to offer further refnames after one has already been given.

If you think that this would be desirable, find a revised version below. 
Otherwise drop it.


On 02/15/2017 04:11 AM, SZEDER Gábor wrote:
> On Tue, Feb 14, 2017 at 10:24 PM,   wrote:
>> From: Cornelius Weig 
>> Note that one corner-case is not covered by the current implementation:
>> if a refname contains a ':' and is followed by '--' the completion would
>> not recognize the valid refname.
> 
> I'm not sure what you mean here.  Refnames can't contain ':'.

Yes, my bad. I was confusing it with the case where filename and ref name are 
identical.

>> +   while [ $c -lt $cword ]; do
>> +   i="${words[c]}"
>> +   case "$i" in
>> +   --) seen_double_dash=1 ;;
>> +   -*|?*:*) ;;
>> +   *) ref="$i"; break ;;
> 
> I haven't tried it, but this would trigger on e.g. 'git checkout -b
> new-feature ', wouldn't it?

Correct, good eyes.

> What about
> 
>   $ echo "unintentional change" >>tracked-file && git add -u
>   $ git rm important-file
>   $ git checkout HEAD 
> 
> ?  It seems it will offer neither 'tracked-file' nor 'important-file',
> but I think it should offer both.

Ideally yes. The latter of the two would also not work with Alt/.


---
>From d0e0c9af8a30dec479c393ae7fe75205c9b3b229 Mon Sep 17 00:00:00 2001
From: Cornelius Weig 
Date: Tue, 14 Feb 2017 21:01:45 +0100
Subject: [PATCH] completion: checkout: complete paths when ref given

Git-checkout completes words starting with '--' as options and other
words as refs. Even after specifying a ref, further words not starting
with '--' are completed as refs, which is invalid for git-checkout.

With this commit completion suppresses refname suggestion after finding
what looks like a refname. Words before a '--' not starting with a '-'
and containing no ':' are considered to be refnames.

Signed-off-by: Cornelius Weig 
---
 contrib/completion/git-completion.bash | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 6c6e1c774d..42e6463b67 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1059,7 +1059,16 @@ _git_bundle ()
 
 _git_checkout ()
 {
-   __git_has_doubledash && return
+   local c=2 seen_ref=""
+   while [ $c -lt $cword ]; do
+   case "${words[c]}" in
+   --) return ;;
+   -b|-B|--orphan|--branch) ((c++)) ;;
+   -*|*:*) ;;
+   *) seen_ref="y" ;;
+   esac
+   ((c++))
+   done
 
case "$cur" in
--conflict=*)
@@ -1072,13 +1081,16 @@ _git_checkout ()
"
;;
*)
-   # check if --track, --no-track, or --no-guess was specified
-   # if so, disable DWIM mode
-   local flags="--track --no-track --no-guess" track=1
-   if [ -n "$(__git_find_on_cmdline "$flags")" ]; then
-   track=''
+   if [ -z "$seen_ref" ]
+   then
+   # check for --track, --no-track, or --no-guess
+   # if so, disable DWIM mode
+   local flags="--track --no-track --no-guess" track=1
+   if [ -n "$(__git_find_on_cmdline "$flags")" ]; then
+   track=''
+   fi
+   __gitcomp_nl "$(__git_refs '' $track)"
fi
-   __gitcomp_nl "$(__git_refs '' $track)"
;;
esac
 }
-- 
2.11.1

Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

[SZEDER Gábor]

On Tue, Feb 14, 2017 at 10:24 PM,   wrote:
> From: Cornelius Weig 
>
> Git-checkout completes words starting with '--' as options and other
> words as refs. Even after specifying a ref, further words not starting
> with '--' are completed as refs, which is invalid for git-checkout.

Refs completion is never attempted for words after the disambiguating
double-dash.

Even when refs completion is attempted, if it is unsuccessful, i.e.
there is no ref that matches the current word to be completed, then
Bash falls back to standard filename completion.  No refs match
'./'.

Furthermore, Bash performs filename completion on Alt-/ independently
from any completion function.

Granted, none of these will limit to only modified files...  But that
might be a good thing, see below.

> This commit ensures that after specifying a ref, further non-option
> words are completed as paths. Four cases are considered:
>
>  - If the word contains a ':', do not treat it as reference and use
>regular revlist completion.
>  - If no ref is found on the command line, complete non-options as refs
>as before.
>  - If the ref is HEAD or @, complete only with modified files because
>checking out unmodified files is a noop.

Here you use "modified" in the 'ls-files --modified' sense, but that
doesn't include modifications already staged in the index, see below.

>This case also applies if no ref is given, but '--' is present.
>  - If a ref other than HEAD or @ is found, offer only valid paths from
>that revision.
>
> Note that one corner-case is not covered by the current implementation:
> if a refname contains a ':' and is followed by '--' the completion would
> not recognize the valid refname.

I'm not sure what you mean here.  Refnames can't contain ':'.

> Signed-off-by: Cornelius Weig 
> ---
>  contrib/completion/git-completion.bash | 39 
> +++---
>  1 file changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash 
> b/contrib/completion/git-completion.bash
> index 4ab119d..df46f62 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1068,7 +1068,7 @@ _git_bundle ()
>
>  _git_checkout ()
>  {
> -   __git_has_doubledash && return
> +   local i c=2 ref="" seen_double_dash=""
>
> case "$cur" in
> --conflict=*)
> @@ -1081,13 +1081,36 @@ _git_checkout ()
> "
> ;;
> *)
> -   # check if --track, --no-track, or --no-guess was specified
> -   # if so, disable DWIM mode
> -   local flags="--track --no-track --no-guess" track=1
> -   if [ -n "$(__git_find_on_cmdline "$flags")" ]; then
> -   track=''
> -   fi
> -   __gitcomp_nl "$(__git_refs '' $track)"
> +   while [ $c -lt $cword ]; do
> +   i="${words[c]}"
> +   case "$i" in
> +   --) seen_double_dash=1 ;;
> +   -*|?*:*) ;;
> +   *) ref="$i"; break ;;

I haven't tried it, but this would trigger on e.g. 'git checkout -b
new-feature ', wouldn't it?

> +   esac
> +   ((c++))
> +   done
> +
> +   case "$ref,$seen_double_dash,$cur" in
> +   ,,*:*)
> +   __git_complete_revlist_file
> +   ;;
> +   ,,*)
> +   # check for --track, --no-track, or --no-guess
> +   # if so, disable DWIM mode
> +   local flags="--track --no-track --no-guess" track=1
> +   if [ -n "$(__git_find_on_cmdline "$flags")" ]; then
> +   track=''
> +   fi
> +   __gitcomp_nl "$(__git_refs '' $track)"
> +   ;;
> +   ,1,*|@,*|HEAD,*)
> +   __git_complete_index_file "--modified"

What about

  $ echo "unintentional change" >>tracked-file && git add -u
  $ git rm important-file
  $ git checkout HEAD 

?  It seems it will offer neither 'tracked-file' nor 'important-file',
but I think it should offer both.


We have __git_complete_index_file() for a while now, but only use it
for commands that accept only --options and filenames, e.g. 'add',
'clean', 'rm'.  This would be the first case when we would use it for
a command that accept both refs and filenames.  Perhaps similar corner
cases and the easy ways to trigger filename completion are why no one
thought it's worth it.

> +   ;;
> +   *)
> +   __git_complete_tree_file "$ref" "$cur"

Well, here you could go all-in, and say that this should complete only
files that are different from the version in $ref, because checking
out files 

Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

[Junio C Hamano]

Cornelius Weig  writes:

> Hmm.. I'm a bit reluctant to let go of this just yet, because it was my
> original motivation for the whole patch. I admit that it may be
> confusing to not get completion in your example. However, I think that
> once acquainted with the new behavior, a user who wants some files
> cleaned would start by having a look at the list of files from "git
> checkout HEAD ". That's probably faster than spelling the
> first few characters and hit  for a file that's already clean.

I understand that "git checkout HEAD frotz" that gives 47 other
paths that all begin with "foo", when "frotz27" is the only one
among them that you know you changed, is not very useful to narrow
things down.  

But it is equally irritating when you know "frotz27" is the only
path that begins with "frotz" (after all, that is why you decided to
stop typing after saying "frotz" and letting the comletion kick in)
but you are not certain if you touched it.  The completion being
silent may be an indication that it is not modified, OR it may be an
indication that you mistyped the leading part "frotz", and leaves
you wondering.

Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

[Cornelius Weig]

On 02/14/2017 10:31 PM, Junio C Hamano wrote:
> cornelius.w...@tngtech.com writes:
> 
>> From: Cornelius Weig 
>>
>> Git-checkout completes words starting with '--' as options and other
>> words as refs. Even after specifying a ref, further words not starting
>> with '--' are completed as refs, which is invalid for git-checkout.
>>
>> This commit ensures that after specifying a ref, further non-option
>> words are completed as paths. Four cases are considered:
>>
>>  - If the word contains a ':', do not treat it as reference and use
>>regular revlist completion.
>>  - If no ref is found on the command line, complete non-options as refs
>>as before.
>>  - If the ref is HEAD or @, complete only with modified files because
>>checking out unmodified files is a noop.
>>This case also applies if no ref is given, but '--' is present.
> 
> Please at least do not do this one; a completion that is or pretends
> to be more clever than the end users will confuse them at best and
> annoy them.  Maybe the user does not recall if she touched the path
> or not, and just trying to be extra sure that it matches HEAD or
> index by doing "git checkout [HEAD] path".  Leave the "make it
> a noop" to Git, but just allow her do so.

Hmm.. I'm a bit reluctant to let go of this just yet, because it was my
original motivation for the whole patch. I admit that it may be
confusing to not get completion in your example. However, I think that
once acquainted with the new behavior, a user who wants some files
cleaned would start by having a look at the list of files from "git
checkout HEAD ". That's probably faster than spelling the
first few characters and hit  for a file that's already clean.
Let's hear if anybody else has an opinion about this.

> I personally feel that "git checkout ... foo" should
> just fall back to the normal "path on the filesystem" without any
> cleverness, instead of opening a tree object or peek into the index.

I was thinking about that as well, but it's not what happens for "git
checkout topic:path". And given that "git checkout topic path"
refers to the same object, consistency kind of demands that the tree
objects are opened in the latter case as well. However, because the
differences to filesystem path completion are somewhat corner cases, I'm
fine with that as long as I'm not offered ref names any longer...

Re: [PATCH v2 2/2] completion: checkout: complete paths when ref given

[Junio C Hamano]

cornelius.w...@tngtech.com writes:

> From: Cornelius Weig 
>
> Git-checkout completes words starting with '--' as options and other
> words as refs. Even after specifying a ref, further words not starting
> with '--' are completed as refs, which is invalid for git-checkout.
>
> This commit ensures that after specifying a ref, further non-option
> words are completed as paths. Four cases are considered:
>
>  - If the word contains a ':', do not treat it as reference and use
>regular revlist completion.
>  - If no ref is found on the command line, complete non-options as refs
>as before.
>  - If the ref is HEAD or @, complete only with modified files because
>checking out unmodified files is a noop.
>This case also applies if no ref is given, but '--' is present.

Please at least do not do this one; a completion that is or pretends
to be more clever than the end users will confuse them at best and
annoy them.  Maybe the user does not recall if she touched the path
or not, and just trying to be extra sure that it matches HEAD or
index by doing "git checkout [HEAD] path".  Leave the "make it
a noop" to Git, but just allow her do so.

I personally feel that "git checkout ... foo" should
just fall back to the normal "path on the filesystem" without any
cleverness, instead of opening a tree object or peek into the index.