bash completion: Fix the . -> .. revision range completion
PATCH 1/1 bash completion: Fix the . -> .. revision range completion
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.
---
contrib/completion/git-completion.bash | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
contrib/completion/git-completion.bash +6 -1
@@ -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)"
Quoted 9 lines · 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.
Modulo s/Git/bash-completion/ ;-) I think this makes sense.
Quoted 5 lines
This patch will make Git perform the . -> .. completion in
__git_complete_revlistonly 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 __git_complete_revlist () · line 328
Quoted 13 lines
contrib/completion/git-completion.bash | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)contrib/completion/git-completion.bash +1
-1@@ -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.
Quoted 3 lines · Junio C Hamano
Quoted 2 lines · 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
...
Quoted 1 line
Quoted 1 line
git log git-submodule.<tab>
...
Quoted 7 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.
--- contrib/completion/git-completion.bash | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-)
contrib/completion/git-completion.bash +0 -3
@@ -324,9 +324,6 @@ __git_complete_revlist () cur="${cur#*..}" __gitcomp "$(__git_refs)" "$pfx" "$cur" ;; - *.) - __gitcomp "$cur." - ;; *) __gitcomp "$(__git_refs)" ;;
Signature · 4 lines
1.5.6.2.393.g45096 -- Shawn.
Quoted 10 lines · Junio C Hamano
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.
Quoted 16 lines
contrib/completion/git-completion.bash __git_complete_revlist () · line 328
Quoted 13 lines
contrib/completion/git-completion.bash | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)contrib/completion/git-completion.bash +1
-1@@ -325,7 +325,12 @@ __git_complete_revlist () __gitcomp "$(__git_refs)" "$pfx" "$cur" ;; *.) - __gitcomp "$cur." + if ls "$cur"* >/dev/null 2>&1; thenThere 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).
Signature · 4 lines
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
Quoted 12 lines · Petr Baudis
Quoted 10 lines · Junio C Hamano
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.
Quoted 4 lines
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.
Quoted 3 lines · Junio C Hamano
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.
Quoted 7 lines · Linus Torvalds
Quoted 3 lines · Junio C Hamano
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:
Quoted 7 lines
git show origin/pu:Makef<tab>
which totally screws up and becomes
git show
Makefiledropping 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.
Signature · 1 line
Shawn.
Quoted 7 lines · Shawn O. Pearce
Quoted 7 lines
Does it fix this one too:
git show origin/pu:Makef<tab>
which totally screws up and becomes
Quoted 8 lines
Quoted 3 lines
git show
Makefiledropping the version specifier?
Its unrelated to the issue you described above. But I just tested your
Makefilecompletion 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(-)
contrib/completion/git-completion.bash +1 -1
@@ -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 /{
Quoted 6 lines · Linus Torvalds
Quoted 5 lines · Shawn O. Pearce
Quoted 5 lines
Does it fix this one too:
git show origin/pu:Makef<tab>
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
which totally screws up and becomes
git show
Makefiledropping the version specifier?
What version of bash do you have?
GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
Quoted 3 lines
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.
Quoted 3 lines
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 ...".
contrib/completion/git-completion.bash __git_complete_file () · line 296
Quoted 13 lines
contrib/completion/git-completion.bash +1
-1@@ -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*
Signature · 1 line
Shawn.
Quoted 11 lines · Linus Torvalds
Quoted 10 lines · Shawn O. Pearce
Quoted 10 lines
Does it fix this one too:
git show origin/pu:Makef<tab>
which totally screws up and becomes
git show
Makefiledropping 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.
Signature · 1 line
Shawn.
Quoted 25 lines · Shawn O. Pearce
Quoted 11 lines · Linus Torvalds
Quoted 10 lines · Shawn O. Pearce
Quoted 10 lines
Does it fix this one too:
git show origin/pu:Makef<tab>
which totally screws up and becomes
git show
Makefiledropping 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_WORDBREAKSwill get the behavior you are reporting as broken.
Quoted 6 lines
I have to say, this sounds to me like you (or some package on your system) modified
COMP_WORDBREAKSaway 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
Quoted 33 lines · Björn Steinbrink
Quoted 25 lines · Shawn O. Pearce
Quoted 11 lines · Linus Torvalds
Quoted 10 lines · Shawn O. Pearce
Quoted 10 lines
Does it fix this one too:
git show origin/pu:Makef<tab>
which totally screws up and becomes
git show
Makefiledropping 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_WORDBREAKSwill get the behavior you are reporting as broken.Quoted 6 lines
I have to say, this sounds to me like you (or some package on your system) modified
COMP_WORDBREAKSaway 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.
Quoted 2 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
Björn, getting some coffee now
Quoted 31 lines · Björn Steinbrink
Quoted 30 lines · Björn Steinbrink
Quoted 29 lines · Shawn O. Pearce
Quoted 10 lines · Linus Torvalds
Quoted 9 lines · Shawn O. Pearce
Quoted 9 lines
Does it fix this one too:
git show origin/pu:Makef<tab>
which totally screws up and becomes
git show
Makefiledropping 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_WORDBREAKSwill 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_WORDBREAKSaway 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.
Quoted 6 lines
Quoted 2 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
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.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Quoted 6 lines · Björn Steinbrink
Quoted 3 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
Quoted 7 lines · Shawn O. Pearce
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 ':'.
Quoted 3 lines
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
Quoted 8 lines · Linus Torvalds
Quoted 5 lines · Shawn O. Pearce
What is $COMP_WORDBREAKS set to in your shell? In mine it appears to be:
" \"'@><=;|&(:"Ahhah. Indeed. I don't have the ':'.
...
Quoted 1 line
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.
Signature · 1 line
Shawn.
Quoted 25 lines · Shawn O. Pearce
Quoted 6 lines · Linus Torvalds
Quoted 4 lines · Shawn O. Pearce
What is $COMP_WORDBREAKS set to in your shell? In mine it appears to be:
" \"'@><=;|&(:"Ahhah. Indeed. I don't have the ':'.
...
Quoted 1 line
Umm, if so, git should just set it in the completion script, no?
OK, so it turns out not having : in
COMP_WORDBREAKSis a very common case that we should somehow deal with, to aid our users.I'm concerned about just setting
COMP_WORDBREAKSback 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 ourCOMP_WORDBREAKSsetting.I think we may need to do two things.
If
COMP_WORDBREAKSdoesn'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. ;-)
Quoted 8 lines
If
COMP_WORDBREAKSdoesn'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 <[email protected]>
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.
---
contrib/completion/git-completion.bash | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
contrib/completion/git-completion.bash +0 -0
@@ -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,^.* ,,
Signature · 6 lines
1.5.6.3.315.g10ce0 -- Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
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.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Quoted 7 lines · 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.
Apparently it wasn't ws-damaged after all. Just my font-settings acting up on me.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Quoted 2 lines · Andreas Ericsson
I beat you to it ;-) This works just fine for me regardless of whether or not I have a colon in
COMP_WORDBREAKS.
...
Quoted 1 line
Subject: git-completion.bash: Handle "rev:path" completion properly
...
Quoted 7 lines
contrib/completion/git-completion.bash +0
-0@@ -293,7 +293,11 @@ __git_complete_file () *) ls="$ref"
contrib/completion/git-completion.bash __git_complete_file () · line 303
Quoted 10 lines
contrib/completion/git-completion.bash +5
-1;; - 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.
Signature · 1 line
Shawn.
Quoted 30 lines · Shawn O. Pearce
Quoted 2 lines · Andreas Ericsson
I beat you to it ;-) This works just fine for me regardless of whether or not I have a colon in
COMP_WORDBREAKS....
Quoted 1 line
Subject: git-completion.bash: Handle "rev:path" completion properly
...
Quoted 7 lines
contrib/completion/git-completion.bash +0
-0@@ -293,7 +293,11 @@ __git_complete_file () *) ls="$ref"contrib/completion/git-completion.bash __git_complete_file () · line 303
Quoted 10 lines
contrib/completion/git-completion.bash +5
-1;; - 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).
Quoted 3 lines
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.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Quoted 5 lines · Petr Baudis
This patch will make Git perform the . -> .. completion in
__git_complete_revlistonly 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...
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git