threads / patch / 14437

patchbash completion: Fix the . -> .. revision range completion

Subject: [PATCH] bash completion: Fix the . -> .. revision range completion

## tl;dr

22 messages between Jul 13, 2008 and Jul 16, 2008. Diffs are folded; open one to read it.

replies: 21people: 7as markdown or json

Petr Baudis· Jul 13, 2008, 11:19 UTC · lore

When Git sees a string with trailing dot on a place where revision range could occur, it will unconditionally append another dot to it to help complete a revision range. However, filespec can usually occur at such a place as well. I have been hitting this all the time lately with

	git log git-submodule.<tab>
and the like.

This patch will make Git perform the . -> .. completion in __git_complete_revlist only if there is no filename starting with the entered prefix available. At few places, filename could not occur when calling __git_complete_revlist; however, taking this into account did not seem worth complicating the code further.

Signed-off-by: Petr Baudis <pasky@suse.cz>
---
 contrib/completion/git-completion.bash |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)
Show changes to contrib/completion/git-completion.bash +6 −1
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 61581fe..fe24b8c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -325,7 +325,12 @@ __git_complete_revlist ()
 		__gitcomp "$(__git_refs)" "$pfx" "$cur"
 		;;
 	*.)
-		__gitcomp "$cur."
+		if ls "$cur"* >/dev/null 2>&1; then
+			# This is a file, not revision range
+			__gitcomp "$(__git_refs)"
+		else
+			__gitcomp "$cur."
+		fi
 		;;
 	*)
 		__gitcomp "$(__git_refs)"
Jakub Narebski· Jul 13, 2008, 12:11 UTC · re: Petr Baudis · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Petr Baudis wrote:
Show 5 quoted lines
> This patch will make Git perform the . -> .. completion in
> __git_complete_revlist only if there is no filename starting with
> the entered prefix available.  At few places, filename could not occur
> when calling __git_complete_revlist; however, taking this into account
> did not seem worth complicating the code further.
Thanks a lot!  This is what I was waiting for...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Junio C Hamano· Jul 13, 2008, 21:38 UTC · re: Petr Baudis · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Petr Baudis <pasky@suse.cz> writes:
Show 9 quoted lines
> When Git sees a string with trailing dot on a place where revision
> range could occur, it will unconditionally append another dot to
> it to help complete a revision range. However, filespec can usually
> occur at such a place as well. I have been hitting this all the time
> lately with
>
> 	git log git-submodule.<tab>
>
> and the like.
Modulo s/Git/bash-completion/ ;-) I think this makes sense.
Show 5 quoted lines
> This patch will make Git perform the . -> .. completion in
> __git_complete_revlist only if there is no filename starting with
> the entered prefix available.  At few places, filename could not occur
> when calling __git_complete_revlist; however, taking this into account
> did not seem worth complicating the code further.

Theoretically we could take a hint from presense of '--' like d773c63 (bash: offer only paths after '--', 2008-07-08) did. If the command line has double-dash and the token we are looking at is before it, it cannot be pathname and this check does not have to trigger. But I agree that is not worth it, because this "theoretical" solution would mean that the user needs to something awkward like:

	git log v1.5.6. --<C-b><C-b><C-b><TAB>
to take advantage of it.

By the way, the above command line is another "dot" related frustration I always have. If you try:

	git log v1.5.6.<TAB>

the completion code adds a dot unconditionally when I want to choose from the list of v1.5.6.X tags. Of course, I can work this around by dropping the last dot before asking for completion, so it is not really a very big deal, but I mention it here because this annoyance is exactly in the same league as your "git-submodule.<TAB>" example.

"git show v1.5.6.<TAB>" does complete as expected, which is understandable (the command does not take range, and completion knows about it -- which is quite nice).

Show 13 quoted lines
>  contrib/completion/git-completion.bash |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 61581fe..fe24b8c 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -325,7 +325,12 @@ __git_complete_revlist ()
>  		__gitcomp "$(__git_refs)" "$pfx" "$cur"
>  		;;
>  	*.)
> -		__gitcomp "$cur."
> +		if ls "$cur"* >/dev/null 2>&1; then

There is a slight Yuck factor for using "ls" here but I do not think of a better alternative offhand.

Will queue on top of Shawn's previous one.  Thanks.
Shawn O. Pearce· Jul 13, 2008, 22:06 UTC · re: Junio C Hamano · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Junio C Hamano <gitster@pobox.com> wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > When Git sees a string with trailing dot on a place where revision
> > range could occur, it will unconditionally append another dot to
...
> > 	git log git-submodule.<tab>
...
Show 7 quoted lines
> By the way, the above command line is another "dot" related frustration I
> always have.  If you try:
> 
> 	git log v1.5.6.<TAB>
> 
> the completion code adds a dot unconditionally when I want to choose from
> the list of v1.5.6.X tags.

This annoys me too Junio. Its a bug I just never got around to fixing. Based on Petr's comments and yours I'm wondering if this is just not the better patch to apply here:

--8<-- bash completion: Don't offer "a.." as a completion for "a."

If the user is trying to complete "v1.5.3.<tab>" to see all of the available maintenance releases for 1.5.3 we should not give them an extra dot as the completion. Instead if the user wants a ".." or a "..." operator they should key the two dots out on their own. Its the same number of keystrokes either way.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 contrib/completion/git-completion.bash |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)
Show changes to contrib/completion/git-completion.bash +0 −3
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 61581fe..9a1c66a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -324,9 +324,6 @@ __git_complete_revlist ()
 		cur="${cur#*..}"
 		__gitcomp "$(__git_refs)" "$pfx" "$cur"
 		;;
-	*.)
-		__gitcomp "$cur."
-		;;
 	*)
 		__gitcomp "$(__git_refs)"
 		;;

-- 
1.5.6.2.393.g45096

-- 
Shawn.
Petr Baudis· Jul 13, 2008, 23:07 UTC · re: Junio C Hamano · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

On Sun, Jul 13, 2008 at 02:38:37PM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> By the way, the above command line is another "dot" related frustration I
> always have.  If you try:
> 
> 	git log v1.5.6.<TAB>
> 
> the completion code adds a dot unconditionally when I want to choose from
> the list of v1.5.6.X tags.  Of course, I can work this around by dropping
> the last dot before asking for completion, so it is not really a very big
> deal, but I mention it here because this annoyance is exactly in the same
> league as your "git-submodule.<TAB>" example.

Actually, my original solution to this problem was simply to remove the . -> .. completion altogether. Maybe this would still be the best course of action? I don't think the . -> .. is actually very useful for anyone, since you might as well just hit the dot another time instead of a tab.

Show 16 quoted lines
> >  contrib/completion/git-completion.bash |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> >
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index 61581fe..fe24b8c 100755
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -325,7 +325,12 @@ __git_complete_revlist ()
> >  		__gitcomp "$(__git_refs)" "$pfx" "$cur"
> >  		;;
> >  	*.)
> > -		__gitcomp "$cur."
> > +		if ls "$cur"* >/dev/null 2>&1; then
> 
> There is a slight Yuck factor for using "ls" here but I do not think of a
> better alternative offhand.

I have thought about this hard for some time, but couldn't come up with anything better than this or

	(shopt -s nullglob; completion=("$cur"*); [ -n "$completion" ])

which looks quite awful (and can waste a lot of memory in case of some really insane completion).

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
Junio C Hamano· Jul 13, 2008, 23:25 UTC · re: Petr Baudis · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Petr Baudis <pasky@suse.cz> writes:
Show 16 quoted lines
> On Sun, Jul 13, 2008 at 02:38:37PM -0700, Junio C Hamano wrote:
>> By the way, the above command line is another "dot" related frustration I
>> always have.  If you try:
>> 
>> 	git log v1.5.6.<TAB>
>> 
>> the completion code adds a dot unconditionally when I want to choose from
>> the list of v1.5.6.X tags.  Of course, I can work this around by dropping
>> the last dot before asking for completion, so it is not really a very big
>> deal, but I mention it here because this annoyance is exactly in the same
>> league as your "git-submodule.<TAB>" example.
>
> Actually, my original solution to this problem was simply to remove the
> . -> .. completion altogether. Maybe this would still be the best course
> of action? I don't think the . -> .. is actually very useful for anyone,
> since you might as well just hit the dot another time instead of a tab.

I think that is what Shawn sent a few minutes ago, so you two are in agreement, and I will be happy with it, too.

Linus Torvalds· Jul 13, 2008, 23:52 UTC · re: Junio C Hamano · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

On Sun, 13 Jul 2008, Junio C Hamano wrote:
> 
> I think that is what Shawn sent a few minutes ago, so you two are in
> agreement, and I will be happy with it, too.
Does it fix this one too:
	git show origin/pu:Makef<tab>
which totally screws up and becomes
	git show Makefile
dropping the version specifier?

I don't speak completion-script, so somebody else would have to fix this really annoying bug (*)

		Linus

(*) Ok, so it's rare. I have been bitten by it something like twice in the last months. But when it happens it's really annoying.

Shawn O. Pearce· Jul 14, 2008, 00:00 UTC · re: Linus Torvalds · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 14 quoted lines
> On Sun, 13 Jul 2008, Junio C Hamano wrote:
> > 
> > I think that is what Shawn sent a few minutes ago, so you two are in
> > agreement, and I will be happy with it, too.
> 
> Does it fix this one too:
> 
> 	git show origin/pu:Makef<tab>
> 
> which totally screws up and becomes
> 
> 	git show Makefile
> 
> dropping the version specifier?
Its unrelated to the issue you described above.  But I just tested
your Makefile completion case and it worked as expected, though
I just found out it doesn't add a trailing space once there is a
unique completion made.  I'll look at another patch to fix that.
 
-- 
Shawn.
Linus Torvalds· Jul 14, 2008, 05:38 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
Show 15 quoted lines
> > 
> > Does it fix this one too:
> > 
> > 	git show origin/pu:Makef<tab>
> > 
> > which totally screws up and becomes
> > 
> > 	git show Makefile
> > 
> > dropping the version specifier?
> 
> Its unrelated to the issue you described above.  But I just tested
> your Makefile completion case and it worked as expected, though
> I just found out it doesn't add a trailing space once there is a
> unique completion made.  I'll look at another patch to fix that.
What version of bash do you have?
It definitely doesn't work for me with 
	GNU bash, version 3.2.33(1)-release (x86_64-redhat-linux-gnu)
and quite frankly, I don't see how it _can_ work.

Something like this seems to be totally missing, and definitely required. How can you say that it works for you? I don't see how that is possible even in theory? Did you actually test it?

		Linus
---
 contrib/completion/git-completion.bash |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Show changes to contrib/completion/git-completion.bash +1 −1
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 27332ed..0a87337 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -290,7 +290,7 @@ __git_complete_file ()
 			ls="$ref"
 			;;
 	    esac
-		COMPREPLY=($(compgen -P "$pfx" \
+		COMPREPLY=($(compgen -P "$ref:$pfx" \
 			-W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
 				| sed '/^100... blob /s,^.*	,,
 				       /^040000 tree /{
Shawn O. Pearce· Jul 14, 2008, 05:57 UTC · re: Linus Torvalds · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 13 quoted lines
> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > > 
> > > Does it fix this one too:
> > > 
> > > 	git show origin/pu:Makef<tab>
> > > 
> > > which totally screws up and becomes
> > > 
> > > 	git show Makefile
> > > 
> > > dropping the version specifier?
> 
> What version of bash do you have?
GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
> It definitely doesn't work for me with 
> 
> 	GNU bash, version 3.2.33(1)-release (x86_64-redhat-linux-gnu)
So between .17 and .33 they changed something.
 
> Something like this seems to be totally missing, and definitely required. 
> How can you say that it works for you? I don't see how that is possible 
> even in theory? Did you actually test it?
Yes, of course dammit, I did test it before writing an email that
said "I tested this ...".
Show 13 quoted lines
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 27332ed..0a87337 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -290,7 +290,7 @@ __git_complete_file ()
>  			ls="$ref"
>  			;;
>  	    esac
> -		COMPREPLY=($(compgen -P "$pfx" \
> +		COMPREPLY=($(compgen -P "$ref:$pfx" \
>  			-W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
>  				| sed '/^100... blob /s,^.*	,,
>  				       /^040000 tree /{

In bash 3.2.17 your change above causes completion to include the ref name _twice_:

	git show jc/html:in<tab>
	git show jc/html:jc/html:index.html

This is not good news because it means we need to perform a version test to identify the correct behavior we need for this shell, and we also have to figure out what version of 3.2.X this changed in. *sigh*

-- 
Shawn.
Shawn O. Pearce· Jul 14, 2008, 06:27 UTC · re: Linus Torvalds · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 11 quoted lines
> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > > 
> > > Does it fix this one too:
> > > 
> > > 	git show origin/pu:Makef<tab>
> > > 
> > > which totally screws up and becomes
> > > 
> > > 	git show Makefile
> > > 
> > > dropping the version specifier?

What is $COMP_WORDBREAKS set to in your shell? In mine it appears to be:

	" \"'@><=;|&(:"
which is the I believe the shell default.

Björn Steinbrink (doener on #git) is running bash 3.2.39 from Debian and has the same setting, and the completion works correctly there too. He reports that removing : from COMP_WORDBREAKS will get the behavior you are reporting as broken.

I have to say, this sounds to me like you (or some package on your system) modified COMP_WORDBREAKS away from the default that other distributions use and that is what is breaking us here. Since we can have only one setting for this variable in the shell I do not thing it would be a good idea for our completion package to force a specific setting upon the user.

Though we could try to detect : in there and if it is not present use the workaround you posted. But I wonder if just asking the user to include : is easier.

-- 
Shawn.
Björn Steinbrink· Jul 14, 2008, 06:47 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:
Show 31 quoted lines
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > > > 
> > > > Does it fix this one too:
> > > > 
> > > > 	git show origin/pu:Makef<tab>
> > > > 
> > > > which totally screws up and becomes
> > > > 
> > > > 	git show Makefile
> > > > 
> > > > dropping the version specifier?
> 
> What is $COMP_WORDBREAKS set to in your shell?  In mine it
> appears to be:
> 
> 	" \"'@><=;|&(:"
> 
> which is the I believe the shell default.
> 
> Björn Steinbrink (doener on #git) is running bash 3.2.39 from
> Debian and has the same setting, and the completion works correctly
> there too.  He reports that removing : from COMP_WORDBREAKS will
> get the behavior you are reporting as broken.
> 
> I have to say, this sounds to me like you (or some package on your
> system) modified COMP_WORDBREAKS away from the default that other
> distributions use and that is what is breaking us here.  Since we
> can have only one setting for this variable in the shell I do not
> thing it would be a good idea for our completion package to force
> a specific setting upon the user.

Seems that gvfs comes with a completion script that deliberately drops the : from COMP_WORDBREAKS. Do you have that installed Linus?

Björn
Björn Steinbrink· Jul 14, 2008, 06:50 UTC · re: Björn Steinbrink · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

On 2008.07.14 08:47:19 +0200, Björn Steinbrink wrote:
Show 35 quoted lines
> On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > > > > 
> > > > > Does it fix this one too:
> > > > > 
> > > > > 	git show origin/pu:Makef<tab>
> > > > > 
> > > > > which totally screws up and becomes
> > > > > 
> > > > > 	git show Makefile
> > > > > 
> > > > > dropping the version specifier?
> > 
> > What is $COMP_WORDBREAKS set to in your shell?  In mine it
> > appears to be:
> > 
> > 	" \"'@><=;|&(:"
> > 
> > which is the I believe the shell default.
> > 
> > Björn Steinbrink (doener on #git) is running bash 3.2.39 from
> > Debian and has the same setting, and the completion works correctly
> > there too.  He reports that removing : from COMP_WORDBREAKS will
> > get the behavior you are reporting as broken.
> > 
> > I have to say, this sounds to me like you (or some package on your
> > system) modified COMP_WORDBREAKS away from the default that other
> > distributions use and that is what is breaking us here.  Since we
> > can have only one setting for this variable in the shell I do not
> > thing it would be a good idea for our completion package to force
> > a specific setting upon the user.
> 
> Seems that gvfs comes with a completion script that deliberately drops
> the : from COMP_WORDBREAKS. Do you have that installed Linus?

Ah crap, I should have mentioned which file I'm talking about... It's /etc/profile.d/gvfs-bash-completion.sh

Björn, getting some coffee now
Andreas Ericsson· Jul 14, 2008, 12:39 UTC · re: Björn Steinbrink · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Björn Steinbrink wrote:
Show 37 quoted lines
> On 2008.07.14 08:47:19 +0200, Björn Steinbrink wrote:
>> On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:
>>> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>>>>>> Does it fix this one too:
>>>>>>
>>>>>> 	git show origin/pu:Makef<tab>
>>>>>>
>>>>>> which totally screws up and becomes
>>>>>>
>>>>>> 	git show Makefile
>>>>>>
>>>>>> dropping the version specifier?
>>> What is $COMP_WORDBREAKS set to in your shell?  In mine it
>>> appears to be:
>>>
>>> 	" \"'@><=;|&(:"
>>>
>>> which is the I believe the shell default.
>>>
>>> Björn Steinbrink (doener on #git) is running bash 3.2.39 from
>>> Debian and has the same setting, and the completion works correctly
>>> there too.  He reports that removing : from COMP_WORDBREAKS will
>>> get the behavior you are reporting as broken.
>>>
>>> I have to say, this sounds to me like you (or some package on your
>>> system) modified COMP_WORDBREAKS away from the default that other
>>> distributions use and that is what is breaking us here.  Since we
>>> can have only one setting for this variable in the shell I do not
>>> thing it would be a good idea for our completion package to force
>>> a specific setting upon the user.
>> Seems that gvfs comes with a completion script that deliberately drops
>> the : from COMP_WORDBREAKS. Do you have that installed Linus?
> 
> Ah crap, I should have mentioned which file I'm talking about... It's
> /etc/profile.d/gvfs-bash-completion.sh
> 
I have that file, and I'm seeing the same issue as Linus.

E13 at http://tiswww.case.edu/php/chet/bash/FAQ mentions it, but doesn't (imo) give a strong reason why it drops colon from COMP_WORDBREAKS, as filenames with colons in them aren't exactly common.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Linus Torvalds· Jul 14, 2008, 14:51 UTC · re: Björn Steinbrink · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

On Mon, 14 Jul 2008, Björn Steinbrink wrote:
Show 6 quoted lines
> > 
> > Seems that gvfs comes with a completion script that deliberately drops
> > the : from COMP_WORDBREAKS. Do you have that installed Linus?
> 
> Ah crap, I should have mentioned which file I'm talking about... It's
> /etc/profile.d/gvfs-bash-completion.sh
Yup. Part of gvfs-0.2.5-1.fc9.x86_64 for me.
		Linus
Linus Torvalds· Jul 14, 2008, 14:50 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
Show 7 quoted lines
> 
> What is $COMP_WORDBREAKS set to in your shell?  In mine it
> appears to be:
> 
> 	" \"'@><=;|&(:"
> 
> which is the I believe the shell default.
Ahhah. Indeed. I don't have the ':'.
> Though we could try to detect : in there and if it is not present
> use the workaround you posted.  But I wonder if just asking the
> user to include : is easier.
Umm, if so, git should just set it in the completion script, no?

And doing a google for 'COMP_WORDBREAKS' and 'colon', I don't think I'm the only one with it unset. In fact, I'm pretty sure I didn't unset it myself, because I've never heard of that thing. So I think it's a generic Fedora 9 thing.

(I just checked - that seems to pan out. All the machines with F9 on it I have access to are missing the ':' - including machines I have not set up myself like master.kernel.org)

		Linus
Shawn O. Pearce· Jul 15, 2008, 04:25 UTC · re: Linus Torvalds · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 8 quoted lines
> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > 
> > What is $COMP_WORDBREAKS set to in your shell?  In mine it
> > appears to be:
> > 
> > 	" \"'@><=;|&(:"
> 
> Ahhah. Indeed. I don't have the ':'.
...
> Umm, if so, git should just set it in the completion script, no?

OK, so it turns out not having : in COMP_WORDBREAKS is a very common case that we should somehow deal with, to aid our users.

I'm concerned about just setting COMP_WORDBREAKS back to the default in the git completion script because then we get into an ordering game with the profile scripts, don't we? If git completion sources before the gvfs script we don't get our COMP_WORDBREAKS setting.

I think we may need to do two things.

If COMP_WORDBREAKS doesn't contain a :, try to reset it to include one when the script is sourced. This may "fix" git completion but make gvfs completion act differently, resulting in a thread on the gvfs lists. ;-)

If COMP_WORDBREAKS doesn't contain : during a completion event than we need to do what your original patch asked, which is to include "$ref:" in the prefix, so the ref isn't lost.

At least we understand the problem now, finally.  I'll try to write
up a patch for it tomorrow.  Unfortunately packing to move has been
really sucking up my time lately.
 
-- 
Shawn.
Andreas Ericsson· Jul 15, 2008, 08:05 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Shawn O. Pearce wrote:
Show 33 quoted lines
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>>> What is $COMP_WORDBREAKS set to in your shell?  In mine it
>>> appears to be:
>>>
>>> 	" \"'@><=;|&(:"
>> Ahhah. Indeed. I don't have the ':'.
> ...
>> Umm, if so, git should just set it in the completion script, no?
> 
> OK, so it turns out not having : in COMP_WORDBREAKS is a very common
> case that we should somehow deal with, to aid our users.
> 
> I'm concerned about just setting COMP_WORDBREAKS back to the default
> in the git completion script because then we get into an ordering
> game with the profile scripts, don't we?  If git completion sources
> before the gvfs script we don't get our COMP_WORDBREAKS setting.
> 
> I think we may need to do two things.
> 
> If COMP_WORDBREAKS doesn't contain a :, try to reset it to include
> one when the script is sourced.  This may "fix" git completion but
> make gvfs completion act differently, resulting in a thread on the
> gvfs lists.  ;-)
> 
> If COMP_WORDBREAKS doesn't contain : during a completion event than
> we need to do what your original patch asked, which is to include
> "$ref:" in the prefix, so the ref isn't lost.
> 
> At least we understand the problem now, finally.  I'll try to write
> up a patch for it tomorrow.  Unfortunately packing to move has been
> really sucking up my time lately.
>

I beat you to it ;-) This works just fine for me regardless of whether or not I have a colon in COMP_WORDBREAKS.

--%<--%<--%<--
From: Andreas Ericsson <ae@op5.se>
Subject: git-completion.bash: Handle "rev:path" completion properly

The gvfs package on at least Fedora9 installs its own bash completion script which removes the colon from COMP_WORDBREAKS, which acts as a list of characters where bash should consider as word boundaries. Doing so breaks the git bash completion script when handling any rev:path style argument.

This patch fixes it by prepending the "rev" part and the colon (which otherwise gets lost) before adding the "path" part if COMP_WORDBREAKS doesn't contain the colon we would otherwise need.

Also fixes a nearby indented-with-spaces issue.
Spotted-by: Linus Torvalds <torvalds@linux-foundation.org>
Investigated-by: Björn Steinbrink <b.steinbrink@gmx.de>
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
 contrib/completion/git-completion.bash |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)
Show changes to contrib/completion/git-completion.bash +5 −1
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d268e6f..e138022 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -293,7 +293,11 @@ __git_complete_file ()
 		*)
 			ls="$ref"
 			;;
-	    esac
+		esac
+		# When completing something like 'rev:path', bash behaves
+		# differently whether or not COMP_WORDBREAKS contains a
+		# colon or not. This lets it handle both cases
+		test "${COMP_WORDBREAKS//:}" = "$COMP_WORDBREAKS" && pfx="$ref:$pfx"
 		COMPREPLY=($(compgen -P "$pfx" \
 			-W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
 				| sed '/^100... blob /s,^.*	,,

-- 
1.5.6.3.315.g10ce0

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Andreas Ericsson· Jul 15, 2008, 08:10 UTC · re: Andreas Ericsson · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Andreas Ericsson wrote:
[ a whitespace damaged patch ]

Sorry about that. I'll try again in a short while. It seems sending patches with thunderbird no longer works like it used to.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Andreas Ericsson· Jul 15, 2008, 08:17 UTC · re: Andreas Ericsson · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Andreas Ericsson wrote:
Show 7 quoted lines
> Andreas Ericsson wrote:
> 
> [ a whitespace damaged patch ]
> 
> Sorry about that. I'll try again in a short while. It seems sending
> patches with thunderbird no longer works like it used to.
>

Apparently it wasn't ws-damaged after all. Just my font-settings acting up on me.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Shawn O. Pearce· Jul 15, 2008, 23:38 UTC · re: Andreas Ericsson · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Andreas Ericsson <ae@op5.se> wrote:
> I beat you to it ;-) This works just fine for me regardless of whether
> or not I have a colon in COMP_WORDBREAKS.
...
> Subject: git-completion.bash: Handle "rev:path" completion properly
...
Show 17 quoted lines
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index d268e6f..e138022 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -293,7 +293,11 @@ __git_complete_file ()
> 		*)
> 			ls="$ref"
> 			;;
> -	    esac
> +		esac
> +		# When completing something like 'rev:path', bash behaves
> +		# differently whether or not COMP_WORDBREAKS contains a
> +		# colon or not. This lets it handle both cases
> +		test "${COMP_WORDBREAKS//:}" = "$COMP_WORDBREAKS" && pfx="$ref:$pfx"
> 		COMPREPLY=($(compgen -P "$pfx" \
> 			-W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
> 				| sed '/^100... blob /s,^.*	,,

Yea, I did more or less the same thing in my patch, but I also handled this fix in git-fetch and git-push. The : is also used there in a refspec and we support completion the right side of the : in both cases (and yes, on git-push that can be slow as we do network IO, possibly over SSH).

So I'm in favor of my patch over yours, but only because of the fetch and push fixes as well.

-- 
Shawn.
Andreas Ericsson· Jul 16, 2008, 07:20 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] bash completion: Fix the . -> .. revision range completion

Shawn O. Pearce wrote:
Show 33 quoted lines
> Andreas Ericsson <ae@op5.se> wrote:
>> I beat you to it ;-) This works just fine for me regardless of whether
>> or not I have a colon in COMP_WORDBREAKS.
> ...
>> Subject: git-completion.bash: Handle "rev:path" completion properly
> ...
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index d268e6f..e138022 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -293,7 +293,11 @@ __git_complete_file ()
>> 		*)
>> 			ls="$ref"
>> 			;;
>> -	    esac
>> +		esac
>> +		# When completing something like 'rev:path', bash behaves
>> +		# differently whether or not COMP_WORDBREAKS contains a
>> +		# colon or not. This lets it handle both cases
>> +		test "${COMP_WORDBREAKS//:}" = "$COMP_WORDBREAKS" && pfx="$ref:$pfx"
>> 		COMPREPLY=($(compgen -P "$pfx" \
>> 			-W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
>> 				| sed '/^100... blob /s,^.*	,,
> 
> Yea, I did more or less the same thing in my patch, but I also
> handled this fix in git-fetch and git-push.  The : is also used
> there in a refspec and we support completion the right side of the
> : in both cases (and yes, on git-push that can be slow as we do
> network IO, possibly over SSH).
> 
> So I'm in favor of my patch over yours, but only because of
> the fetch and push fixes as well.
>

I agree, although I'd rather not have seen the case statement in yours. It's bash completion after all, so no need to be "portably fast" ;-)

I don't care that much though so long as it gets fixed.
-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

← back to recent threads