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

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

[Petr Baudis]

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(-)

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)"

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

[Jakub Narebski]

Petr Baudis wrote:

> 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

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

[Junio C Hamano]

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
> 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.

> 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).

>  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.

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

[Shawn O. Pearce]

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>
...
> 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(-)

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.

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

[Petr Baudis]

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.

> >  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

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

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> 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.

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

[Linus Torvalds]

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.

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

[Shawn O. Pearce]

Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 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.

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

[Linus Torvalds]

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?
> 
> 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(-)

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 /{

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

[Shawn O. Pearce]

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 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 ...".
 
> 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.

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

[Shawn O. Pearce]

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.

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.

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

[Björn Steinbrink]

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?

Björn

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

[Björn Steinbrink]

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

Björn, getting some coffee now

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

[Andreas Ericsson]

Björn Steinbrink wrote:
> 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

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

[Linus Torvalds]

On Mon, 14 Jul 2008, Björn Steinbrink wrote:
> > 
> > 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

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

[Linus Torvalds]

On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> 
> 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

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

[Shawn O. Pearce]

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.
 
-- 
Shawn.

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

[Andreas Ericsson]

Shawn O. Pearce wrote:
> 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(-)

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

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

[Andreas Ericsson]

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

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

[Andreas Ericsson]

Andreas Ericsson wrote:
> 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

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

[Shawn O. Pearce]

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.

-- 
Shawn.

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

[Andreas Ericsson]

Shawn O. Pearce wrote:
> 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