{"thread":{"id":"14437","subject":"[PATCH] bash completion: Fix the . -> .. revision range completion","startedAt":"2008-07-13T11:19:58Z","lastAt":"2008-07-16T07:20:24Z","messageCount":22,"participants":["Petr Baudis","Jakub Narebski","Junio C Hamano","Shawn O. Pearce","Linus Torvalds","Björn Steinbrink","Andreas Ericsson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"83136","messageId":"20080713111847.29801.8969.stgit@localhost","threadId":"14437","inReplyTo":null,"subject":"[PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-13T11:19:58Z","receivedAt":"2008-07-13T11:19:58Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"When Git sees a string with trailing dot on a place where revision\nrange could occur, it will unconditionally append another dot to\nit to help complete a revision range. However, filespec can usually\noccur at such a place as well. I have been hitting this all the time\nlately with\n\n\tgit log git-submodule.\n\nand the like.\n\nThis patch will make Git perform the . -> .. completion in\n__git_complete_revlist only if there is no filename starting with\nthe entered prefix available. At few places, filename could not occur\nwhen calling __git_complete_revlist; however, taking this into account\ndid not seem worth complicating the code further.\n\nSigned-off-by: Petr Baudis \n---\n\n contrib/completion/git-completion.bash | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 61581fe..fe24b8c 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -325,7 +325,12 @@ __git_complete_revlist ()\n \t\t__gitcomp \"$(__git_refs)\" \"$pfx\" \"$cur\"\n \t\t;;\n \t*.)\n-\t\t__gitcomp \"$cur.\"\n+\t\tif ls \"$cur\"* >/dev/null 2>&1; then\n+\t\t\t# This is a file, not revision range\n+\t\t\t__gitcomp \"$(__git_refs)\"\n+\t\telse\n+\t\t\t__gitcomp \"$cur.\"\n+\t\tfi\n \t\t;;\n \t*)\n \t\t__gitcomp \"$(__git_refs)\"\n"},{"id":"83145","messageId":"g5crdp$u30$1@ger.gmane.org","threadId":"14437","inReplyTo":"20080713111847.29801.8969.stgit@localhost","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-13T12:11:38Z","receivedAt":"2008-07-13T12:11:38Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n\n> This patch will make Git perform the . -> .. completion in\n> __git_complete_revlist only if there is no filename starting with\n> the entered prefix available.  At few places, filename could not occur\n> when calling __git_complete_revlist; however, taking this into account\n> did not seem worth complicating the code further.\n\nThanks a lot! This is what I was waiting for...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"83183","messageId":"7vskudpiqq.fsf@gitster.siamese.dyndns.org","threadId":"14437","inReplyTo":"20080713111847.29801.8969.stgit@localhost","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-13T21:38:37Z","receivedAt":"2008-07-13T21:38:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> When Git sees a string with trailing dot on a place where revision\n> range could occur, it will unconditionally append another dot to\n> it to help complete a revision range. However, filespec can usually\n> occur at such a place as well. I have been hitting this all the time\n> lately with\n>\n> \tgit log git-submodule.\n>\n> and the like.\n\nModulo s/Git/bash-completion/ ;-) I think this makes sense.\n\n> This patch will make Git perform the . -> .. completion in\n> __git_complete_revlist only if there is no filename starting with\n> the entered prefix available. At few places, filename could not occur\n> when calling __git_complete_revlist; however, taking this into account\n> did not seem worth complicating the code further.\n\nTheoretically we could take a hint from presense of '--' like d773c63\n(bash: offer only paths after '--', 2008-07-08) did. If the command line\nhas double-dash and the token we are looking at is before it, it cannot be\npathname and this check does not have to trigger. But I agree that is not\nworth it, because this \"theoretical\" solution would mean that the user\nneeds to something awkward like:\n\n\tgit log v1.5.6. --\n\nto take advantage of it.\n\nBy the way, the above command line is another \"dot\" related frustration I\nalways have. If you try:\n\n\tgit log v1.5.6.\n\nthe completion code adds a dot unconditionally when I want to choose from\nthe list of v1.5.6.X tags. Of course, I can work this around by dropping\nthe last dot before asking for completion, so it is not really a very big\ndeal, but I mention it here because this annoyance is exactly in the same\nleague as your \"git-submodule.\" example.\n\n\"git show v1.5.6.\" does complete as expected, which is understandable\n(the command does not take range, and completion knows about it -- which\nis quite nice).\n\n> contrib/completion/git-completion.bash | 7 ++++++-\n> 1 files changed, 6 insertions(+), 1 deletions(-)\n>\n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index 61581fe..fe24b8c 100755\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -325,7 +325,12 @@ __git_complete_revlist ()\n> \t\t__gitcomp \"$(__git_refs)\" \"$pfx\" \"$cur\"\n> \t\t;;\n> \t*.)\n> -\t\t__gitcomp \"$cur.\"\n> +\t\tif ls \"$cur\"* >/dev/null 2>&1; then\n\nThere is a slight Yuck factor for using \"ls\" here but I do not think of a\nbetter alternative offhand.\n\nWill queue on top of Shawn's previous one. Thanks.\n"},{"id":"83187","messageId":"20080713220631.GB12708@spearce.org","threadId":"14437","inReplyTo":"7vskudpiqq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-13T22:06:31Z","receivedAt":"2008-07-13T22:06:31Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Petr Baudis writes:\n> > When Git sees a string with trailing dot on a place where revision\n> > range could occur, it will unconditionally append another dot to\n...\n> > \tgit log git-submodule.\n...\n> By the way, the above command line is another \"dot\" related frustration I\n> always have. If you try:\n> \n> \tgit log v1.5.6.\n> \n> the completion code adds a dot unconditionally when I want to choose from\n> the list of v1.5.6.X tags.\n\nThis annoys me too Junio. Its a bug I just never got around to fixing.\nBased on Petr's comments and yours I'm wondering if this is just not the\nbetter patch to apply here:\n\n--8<--\nbash completion: Don't offer \"a..\" as a completion for \"a.\"\n\nIf the user is trying to complete \"v1.5.3.\" to see all of\nthe available maintenance releases for 1.5.3 we should not give\nthem an extra dot as the completion. Instead if the user wants\na \"..\" or a \"...\" operator they should key the two dots out on\ntheir own. Its the same number of keystrokes either way.\n\nSigned-off-by: Shawn O. Pearce \n---\n contrib/completion/git-completion.bash | 3 ---\n 1 files changed, 0 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 61581fe..9a1c66a 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -324,9 +324,6 @@ __git_complete_revlist ()\n \t\tcur=\"${cur#*..}\"\n \t\t__gitcomp \"$(__git_refs)\" \"$pfx\" \"$cur\"\n \t\t;;\n-\t*.)\n-\t\t__gitcomp \"$cur.\"\n-\t\t;;\n \t*)\n \t\t__gitcomp \"$(__git_refs)\"\n \t\t;;\n-- \n1.5.6.2.393.g45096\n\n-- \nShawn.\n"},{"id":"83193","messageId":"20080713230724.GJ10151@machine.or.cz","threadId":"14437","inReplyTo":"7vskudpiqq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-13T23:07:24Z","receivedAt":"2008-07-13T23:07:24Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Jul 13, 2008 at 02:38:37PM -0700, Junio C Hamano wrote:\n> By the way, the above command line is another \"dot\" related frustration I\n> always have. If you try:\n> \n> \tgit log v1.5.6.\n> \n> the completion code adds a dot unconditionally when I want to choose from\n> the list of v1.5.6.X tags. Of course, I can work this around by dropping\n> the last dot before asking for completion, so it is not really a very big\n> deal, but I mention it here because this annoyance is exactly in the same\n> league as your \"git-submodule.\" example.\n\nActually, my original solution to this problem was simply to remove the\n. -> .. completion altogether. Maybe this would still be the best course\nof action? I don't think the . -> .. is actually very useful for anyone,\nsince you might as well just hit the dot another time instead of a tab.\n\n> > contrib/completion/git-completion.bash | 7 ++++++-\n> > 1 files changed, 6 insertions(+), 1 deletions(-)\n> >\n> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> > index 61581fe..fe24b8c 100755\n> > --- a/contrib/completion/git-completion.bash\n> > +++ b/contrib/completion/git-completion.bash\n> > @@ -325,7 +325,12 @@ __git_complete_revlist ()\n> > \t\t__gitcomp \"$(__git_refs)\" \"$pfx\" \"$cur\"\n> > \t\t;;\n> > \t*.)\n> > -\t\t__gitcomp \"$cur.\"\n> > +\t\tif ls \"$cur\"* >/dev/null 2>&1; then\n> \n> There is a slight Yuck factor for using \"ls\" here but I do not think of a\n> better alternative offhand.\n\nI have thought about this hard for some time, but couldn't come up with\nanything better than this or\n\n\t(shopt -s nullglob; completion=(\"$cur\"*); [ -n \"$completion\" ])\n\nwhich looks quite awful (and can waste a lot of memory in case of some\nreally insane completion).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nGNU, n. An animal of South Africa, which in its domesticated state\nresembles a horse, a buffalo and a stag. In its wild condition it is\nsomething like a thunderbolt, an earthquake and a cyclone. -- A. Pierce\n"},{"id":"83194","messageId":"7vhcatnz80.fsf@gitster.siamese.dyndns.org","threadId":"14437","inReplyTo":"20080713230724.GJ10151@machine.or.cz","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-13T23:25:35Z","receivedAt":"2008-07-13T23:25:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Sun, Jul 13, 2008 at 02:38:37PM -0700, Junio C Hamano wrote:\n>> By the way, the above command line is another \"dot\" related frustration I\n>> always have. If you try:\n>> \n>> \tgit log v1.5.6.\n>> \n>> the completion code adds a dot unconditionally when I want to choose from\n>> the list of v1.5.6.X tags. Of course, I can work this around by dropping\n>> the last dot before asking for completion, so it is not really a very big\n>> deal, but I mention it here because this annoyance is exactly in the same\n>> league as your \"git-submodule.\" example.\n>\n> Actually, my original solution to this problem was simply to remove the\n> . -> .. completion altogether. Maybe this would still be the best course\n> of action? I don't think the . -> .. is actually very useful for anyone,\n> since you might as well just hit the dot another time instead of a tab.\n\nI think that is what Shawn sent a few minutes ago, so you two are in\nagreement, and I will be happy with it, too.\n"},{"id":"83197","messageId":"alpine.LFD.1.10.0807131649380.3305@woody.linux-foundation.org","threadId":"14437","inReplyTo":"7vhcatnz80.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-13T23:52:22Z","receivedAt":"2008-07-13T23:52:22Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 13 Jul 2008, Junio C Hamano wrote:\n> \n> I think that is what Shawn sent a few minutes ago, so you two are in\n> agreement, and I will be happy with it, too.\n\nDoes it fix this one too:\n\n\tgit show origin/pu:Makef\n\nwhich totally screws up and becomes\n\n\tgit show Makefile\n\ndropping the version specifier?\n\nI don't speak completion-script, so somebody else would have to fix this \nreally annoying bug (*)\n\n\t\tLinus\n\n(*) Ok, so it's rare. I have been bitten by it something like twice in the \nlast months. But when it happens it's really annoying.\n"},{"id":"83199","messageId":"20080714000021.GB13066@spearce.org","threadId":"14437","inReplyTo":"alpine.LFD.1.10.0807131649380.3305@woody.linux-foundation.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-14T00:00:21Z","receivedAt":"2008-07-14T00:00:21Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Sun, 13 Jul 2008, Junio C Hamano wrote:\n> > \n> > I think that is what Shawn sent a few minutes ago, so you two are in\n> > agreement, and I will be happy with it, too.\n> \n> Does it fix this one too:\n> \n> \tgit show origin/pu:Makef\n> \n> which totally screws up and becomes\n> \n> \tgit show Makefile\n> \n> dropping the version specifier?\n\nIts unrelated to the issue you described above. But I just tested\nyour Makefile completion case and it worked as expected, though\nI just found out it doesn't add a trailing space once there is a\nunique completion made. I'll look at another patch to fix that.\n \n-- \nShawn.\n"},{"id":"83215","messageId":"alpine.LFD.1.10.0807132210430.3305@woody.linux-foundation.org","threadId":"14437","inReplyTo":"20080714000021.GB13066@spearce.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-14T05:38:30Z","receivedAt":"2008-07-14T05:38:30Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n> > \n> > Does it fix this one too:\n> > \n> > \tgit show origin/pu:Makef\n> > \n> > which totally screws up and becomes\n> > \n> > \tgit show Makefile\n> > \n> > dropping the version specifier?\n> \n> Its unrelated to the issue you described above. But I just tested\n> your Makefile completion case and it worked as expected, though\n> I just found out it doesn't add a trailing space once there is a\n> unique completion made. I'll look at another patch to fix that.\n\nWhat version of bash do you have?\n\nIt definitely doesn't work for me with \n\n\tGNU bash, version 3.2.33(1)-release (x86_64-redhat-linux-gnu)\n\nand quite frankly, I don't see how it _can_ work.\n\nSomething like this seems to be totally missing, and definitely required. \nHow can you say that it works for you? I don't see how that is possible \neven in theory? Did you actually test it?\n\n\t\tLinus\n\n---\n contrib/completion/git-completion.bash | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 27332ed..0a87337 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -290,7 +290,7 @@ __git_complete_file ()\n \t\t\tls=\"$ref\"\n \t\t\t;;\n \t esac\n-\t\tCOMPREPLY=($(compgen -P \"$pfx\" \\\n+\t\tCOMPREPLY=($(compgen -P \"$ref:$pfx\" \\\n \t\t\t-W \"$(git --git-dir=\"$(__gitdir)\" ls-tree \"$ls\" \\\n \t\t\t\t| sed '/^100... blob /s,^.*\t,,\n \t\t\t\t /^040000 tree /{\n"},{"id":"83217","messageId":"20080714055712.GB15793@spearce.org","threadId":"14437","inReplyTo":"alpine.LFD.1.10.0807132210430.3305@woody.linux-foundation.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-14T05:57:12Z","receivedAt":"2008-07-14T05:57:12Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n> > > \n> > > Does it fix this one too:\n> > > \n> > > \tgit show origin/pu:Makef\n> > > \n> > > which totally screws up and becomes\n> > > \n> > > \tgit show Makefile\n> > > \n> > > dropping the version specifier?\n> \n> What version of bash do you have?\n\nGNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)\n\n> It definitely doesn't work for me with \n> \n> \tGNU bash, version 3.2.33(1)-release (x86_64-redhat-linux-gnu)\n\nSo between .17 and .33 they changed something.\n \n> Something like this seems to be totally missing, and definitely required. \n> How can you say that it works for you? I don't see how that is possible \n> even in theory? Did you actually test it?\n\nYes, of course dammit, I did test it before writing an email that\nsaid \"I tested this ...\".\n \n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index 27332ed..0a87337 100755\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -290,7 +290,7 @@ __git_complete_file ()\n> \t\t\tls=\"$ref\"\n> \t\t\t;;\n> \t esac\n> -\t\tCOMPREPLY=($(compgen -P \"$pfx\" \\\n> +\t\tCOMPREPLY=($(compgen -P \"$ref:$pfx\" \\\n> \t\t\t-W \"$(git --git-dir=\"$(__gitdir)\" ls-tree \"$ls\" \\\n> \t\t\t\t| sed '/^100... blob /s,^.*\t,,\n> \t\t\t\t /^040000 tree /{\n\nIn bash 3.2.17 your change above causes completion to include the\nref name _twice_:\n\n\tgit show jc/html:in\n\tgit show jc/html:jc/html:index.html\n\nThis is not good news because it means we need to perform a version\ntest to identify the correct behavior we need for this shell, and\nwe also have to figure out what version of 3.2.X this changed in.\n*sigh*\n\n-- \nShawn.\n"},{"id":"83218","messageId":"20080714062755.GA15992@spearce.org","threadId":"14437","inReplyTo":"alpine.LFD.1.10.0807132210430.3305@woody.linux-foundation.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-14T06:27:55Z","receivedAt":"2008-07-14T06:27:55Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n> > > \n> > > Does it fix this one too:\n> > > \n> > > \tgit show origin/pu:Makef\n> > > \n> > > which totally screws up and becomes\n> > > \n> > > \tgit show Makefile\n> > > \n> > > dropping the version specifier?\n\nWhat is $COMP_WORDBREAKS set to in your shell? In mine it\nappears to be:\n\n\t\" \\\"'@><=;|&(:\"\n\nwhich is the I believe the shell default.\n\nBjörn Steinbrink (doener on #git) is running bash 3.2.39 from\nDebian and has the same setting, and the completion works correctly\nthere too. He reports that removing : from COMP_WORDBREAKS will\nget the behavior you are reporting as broken.\n\nI have to say, this sounds to me like you (or some package on your\nsystem) modified COMP_WORDBREAKS away from the default that other\ndistributions use and that is what is breaking us here. Since we\ncan have only one setting for this variable in the shell I do not\nthing it would be a good idea for our completion package to force\na specific setting upon the user.\n\nThough we could try to detect : in there and if it is not present\nuse the workaround you posted. But I wonder if just asking the\nuser to include : is easier.\n\n-- \nShawn.\n"},{"id":"83224","messageId":"20080714064719.GA26446@atjola.homenet","threadId":"14437","inReplyTo":"20080714062755.GA15992@spearce.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-07-14T06:47:19Z","receivedAt":"2008-07-14T06:47:19Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:\n> Linus Torvalds wrote:\n> > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n> > > > \n> > > > Does it fix this one too:\n> > > > \n> > > > \tgit show origin/pu:Makef\n> > > > \n> > > > which totally screws up and becomes\n> > > > \n> > > > \tgit show Makefile\n> > > > \n> > > > dropping the version specifier?\n> \n> What is $COMP_WORDBREAKS set to in your shell? In mine it\n> appears to be:\n> \n> \t\" \\\"'@><=;|&(:\"\n> \n> which is the I believe the shell default.\n> \n> Björn Steinbrink (doener on #git) is running bash 3.2.39 from\n> Debian and has the same setting, and the completion works correctly\n> there too. He reports that removing : from COMP_WORDBREAKS will\n> get the behavior you are reporting as broken.\n> \n> I have to say, this sounds to me like you (or some package on your\n> system) modified COMP_WORDBREAKS away from the default that other\n> distributions use and that is what is breaking us here. Since we\n> can have only one setting for this variable in the shell I do not\n> thing it would be a good idea for our completion package to force\n> a specific setting upon the user.\n\nSeems that gvfs comes with a completion script that deliberately drops\nthe : from COMP_WORDBREAKS. Do you have that installed Linus?\n\nBjörn\n"},{"id":"83225","messageId":"20080714065018.GB26446@atjola.homenet","threadId":"14437","inReplyTo":"20080714064719.GA26446@atjola.homenet","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-07-14T06:50:18Z","receivedAt":"2008-07-14T06:50:18Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.07.14 08:47:19 +0200, Björn Steinbrink wrote:\n> On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:\n> > Linus Torvalds wrote:\n> > > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n> > > > > \n> > > > > Does it fix this one too:\n> > > > > \n> > > > > \tgit show origin/pu:Makef\n> > > > > \n> > > > > which totally screws up and becomes\n> > > > > \n> > > > > \tgit show Makefile\n> > > > > \n> > > > > dropping the version specifier?\n> > \n> > What is $COMP_WORDBREAKS set to in your shell? In mine it\n> > appears to be:\n> > \n> > \t\" \\\"'@><=;|&(:\"\n> > \n> > which is the I believe the shell default.\n> > \n> > Björn Steinbrink (doener on #git) is running bash 3.2.39 from\n> > Debian and has the same setting, and the completion works correctly\n> > there too. He reports that removing : from COMP_WORDBREAKS will\n> > get the behavior you are reporting as broken.\n> > \n> > I have to say, this sounds to me like you (or some package on your\n> > system) modified COMP_WORDBREAKS away from the default that other\n> > distributions use and that is what is breaking us here. Since we\n> > can have only one setting for this variable in the shell I do not\n> > thing it would be a good idea for our completion package to force\n> > a specific setting upon the user.\n> \n> Seems that gvfs comes with a completion script that deliberately drops\n> the : from COMP_WORDBREAKS. Do you have that installed Linus?\n\nAh crap, I should have mentioned which file I'm talking about... It's\n/etc/profile.d/gvfs-bash-completion.sh\n\nBjörn, getting some coffee now\n"},{"id":"83260","messageId":"487B4910.5030509@op5.se","threadId":"14437","inReplyTo":"20080714065018.GB26446@atjola.homenet","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-07-14T12:39:44Z","receivedAt":"2008-07-14T12:39:44Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Björn Steinbrink wrote:\n> On 2008.07.14 08:47:19 +0200, Björn Steinbrink wrote:\n>> On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:\n>>> Linus Torvalds wrote:\n>>>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n>>>>>> Does it fix this one too:\n>>>>>>\n>>>>>> \tgit show origin/pu:Makef\n>>>>>>\n>>>>>> which totally screws up and becomes\n>>>>>>\n>>>>>> \tgit show Makefile\n>>>>>>\n>>>>>> dropping the version specifier?\n>>> What is $COMP_WORDBREAKS set to in your shell? In mine it\n>>> appears to be:\n>>>\n>>> \t\" \\\"'@><=;|&(:\"\n>>>\n>>> which is the I believe the shell default.\n>>>\n>>> Björn Steinbrink (doener on #git) is running bash 3.2.39 from\n>>> Debian and has the same setting, and the completion works correctly\n>>> there too. He reports that removing : from COMP_WORDBREAKS will\n>>> get the behavior you are reporting as broken.\n>>>\n>>> I have to say, this sounds to me like you (or some package on your\n>>> system) modified COMP_WORDBREAKS away from the default that other\n>>> distributions use and that is what is breaking us here. Since we\n>>> can have only one setting for this variable in the shell I do not\n>>> thing it would be a good idea for our completion package to force\n>>> a specific setting upon the user.\n>> Seems that gvfs comes with a completion script that deliberately drops\n>> the : from COMP_WORDBREAKS. Do you have that installed Linus?\n> \n> Ah crap, I should have mentioned which file I'm talking about... It's\n> /etc/profile.d/gvfs-bash-completion.sh\n> \n\nI have that file, and I'm seeing the same issue as Linus.\n\nE13 at http://tiswww.case.edu/php/chet/bash/FAQ mentions it, but\ndoesn't (imo) give a strong reason why it drops colon from\nCOMP_WORDBREAKS, as filenames with colons in them aren't exactly\ncommon.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"83267","messageId":"alpine.LFD.1.10.0807140741580.3305@woody.linux-foundation.org","threadId":"14437","inReplyTo":"20080714062755.GA15992@spearce.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-14T14:50:07Z","receivedAt":"2008-07-14T14:50:07Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n> \n> What is $COMP_WORDBREAKS set to in your shell? In mine it\n> appears to be:\n> \n> \t\" \\\"'@><=;|&(:\"\n> \n> which is the I believe the shell default.\n\nAhhah. Indeed. I don't have the ':'.\n\n> Though we could try to detect : in there and if it is not present\n> use the workaround you posted. But I wonder if just asking the\n> user to include : is easier.\n\nUmm, if so, git should just set it in the completion script, no?\n\nAnd doing a google for 'COMP_WORDBREAKS' and 'colon', I don't think I'm \nthe only one with it unset. In fact, I'm pretty sure I didn't unset it \nmyself, because I've never heard of that thing. So I think it's a generic \nFedora 9 thing.\n\n(I just checked - that seems to pan out. All the machines with F9 on it I \nhave access to are missing the ':' - including machines I have not set up \nmyself like master.kernel.org)\n\n\t\tLinus\n"},{"id":"83268","messageId":"alpine.LFD.1.10.0807140751090.3305@woody.linux-foundation.org","threadId":"14437","inReplyTo":"20080714065018.GB26446@atjola.homenet","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-14T14:51:54Z","receivedAt":"2008-07-14T14:51:54Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 14 Jul 2008, Björn Steinbrink wrote:\n> > \n> > Seems that gvfs comes with a completion script that deliberately drops\n> > the : from COMP_WORDBREAKS. Do you have that installed Linus?\n> \n> Ah crap, I should have mentioned which file I'm talking about... It's\n> /etc/profile.d/gvfs-bash-completion.sh\n\nYup. Part of gvfs-0.2.5-1.fc9.x86_64 for me.\n\n\t\tLinus\n"},{"id":"83355","messageId":"20080715042553.GD2432@spearce.org","threadId":"14437","inReplyTo":"alpine.LFD.1.10.0807140741580.3305@woody.linux-foundation.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-15T04:25:53Z","receivedAt":"2008-07-15T04:25:53Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n> > \n> > What is $COMP_WORDBREAKS set to in your shell? In mine it\n> > appears to be:\n> > \n> > \t\" \\\"'@><=;|&(:\"\n> \n> Ahhah. Indeed. I don't have the ':'.\n...\n> Umm, if so, git should just set it in the completion script, no?\n\nOK, so it turns out not having : in COMP_WORDBREAKS is a very common\ncase that we should somehow deal with, to aid our users.\n\nI'm concerned about just setting COMP_WORDBREAKS back to the default\nin the git completion script because then we get into an ordering\ngame with the profile scripts, don't we? If git completion sources\nbefore the gvfs script we don't get our COMP_WORDBREAKS setting.\n\nI think we may need to do two things.\n\nIf COMP_WORDBREAKS doesn't contain a :, try to reset it to include\none when the script is sourced. This may \"fix\" git completion but\nmake gvfs completion act differently, resulting in a thread on the\ngvfs lists. ;-)\n\nIf COMP_WORDBREAKS doesn't contain : during a completion event than\nwe need to do what your original patch asked, which is to include\n\"$ref:\" in the prefix, so the ref isn't lost.\n\nAt least we understand the problem now, finally. I'll try to write\nup a patch for it tomorrow. Unfortunately packing to move has been\nreally sucking up my time lately.\n \n-- \nShawn.\n"},{"id":"83374","messageId":"487C5A2D.3000707@op5.se","threadId":"14437","inReplyTo":"20080715042553.GD2432@spearce.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-07-15T08:05:01Z","receivedAt":"2008-07-15T08:05:01Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> Linus Torvalds wrote:\n>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:\n>>> What is $COMP_WORDBREAKS set to in your shell? In mine it\n>>> appears to be:\n>>>\n>>> \t\" \\\"'@><=;|&(:\"\n>> Ahhah. Indeed. I don't have the ':'.\n> ...\n>> Umm, if so, git should just set it in the completion script, no?\n> \n> OK, so it turns out not having : in COMP_WORDBREAKS is a very common\n> case that we should somehow deal with, to aid our users.\n> \n> I'm concerned about just setting COMP_WORDBREAKS back to the default\n> in the git completion script because then we get into an ordering\n> game with the profile scripts, don't we? If git completion sources\n> before the gvfs script we don't get our COMP_WORDBREAKS setting.\n> \n> I think we may need to do two things.\n> \n> If COMP_WORDBREAKS doesn't contain a :, try to reset it to include\n> one when the script is sourced. This may \"fix\" git completion but\n> make gvfs completion act differently, resulting in a thread on the\n> gvfs lists. ;-)\n> \n> If COMP_WORDBREAKS doesn't contain : during a completion event than\n> we need to do what your original patch asked, which is to include\n> \"$ref:\" in the prefix, so the ref isn't lost.\n> \n> At least we understand the problem now, finally. I'll try to write\n> up a patch for it tomorrow. Unfortunately packing to move has been\n> really sucking up my time lately.\n> \n\nI beat you to it ;-) This works just fine for me regardless of whether\nor not I have a colon in COMP_WORDBREAKS.\n\n--%<--%<--%<--\nFrom: Andreas Ericsson \nSubject: git-completion.bash: Handle \"rev:path\" completion properly\n\nThe gvfs package on at least Fedora9 installs its own bash\ncompletion script which removes the colon from COMP_WORDBREAKS,\nwhich acts as a list of characters where bash should consider\nas word boundaries. Doing so breaks the git bash completion\nscript when handling any rev:path style argument.\n\nThis patch fixes it by prepending the \"rev\" part and the colon\n(which otherwise gets lost) before adding the \"path\" part if\nCOMP_WORDBREAKS doesn't contain the colon we would otherwise\nneed.\n\nAlso fixes a nearby indented-with-spaces issue.\n\nSpotted-by: Linus Torvalds \nInvestigated-by: Björn Steinbrink \nSigned-off-by: Andreas Ericsson \n---\n contrib/completion/git-completion.bash | 6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex d268e6f..e138022 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -293,7 +293,11 @@ __git_complete_file ()\n \t\t*)\n \t\t\tls=\"$ref\"\n \t\t\t;;\n-\t esac\n+\t\tesac\n+\t\t# When completing something like 'rev:path', bash behaves\n+\t\t# differently whether or not COMP_WORDBREAKS contains a\n+\t\t# colon or not. This lets it handle both cases\n+\t\ttest \"${COMP_WORDBREAKS//:}\" = \"$COMP_WORDBREAKS\" && pfx=\"$ref:$pfx\"\n \t\tCOMPREPLY=($(compgen -P \"$pfx\" \\\n \t\t\t-W \"$(git --git-dir=\"$(__gitdir)\" ls-tree \"$ls\" \\\n \t\t\t\t| sed '/^100... blob /s,^.*\t,,\n-- \n1.5.6.3.315.g10ce0\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"83375","messageId":"487C5B72.5040502@op5.se","threadId":"14437","inReplyTo":"487C5A2D.3000707@op5.se","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-07-15T08:10:26Z","receivedAt":"2008-07-15T08:10:26Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Andreas Ericsson wrote:\n\n[ a whitespace damaged patch ]\n\nSorry about that. I'll try again in a short while. It seems sending\npatches with thunderbird no longer works like it used to.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"83376","messageId":"487C5D21.2040703@op5.se","threadId":"14437","inReplyTo":"487C5B72.5040502@op5.se","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-07-15T08:17:37Z","receivedAt":"2008-07-15T08:17:37Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Andreas Ericsson wrote:\n> Andreas Ericsson wrote:\n> \n> [ a whitespace damaged patch ]\n> \n> Sorry about that. I'll try again in a short while. It seems sending\n> patches with thunderbird no longer works like it used to.\n> \n\nApparently it wasn't ws-damaged after all. Just my font-settings\nacting up on me.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"83450","messageId":"20080715233851.GA23672@spearce.org","threadId":"14437","inReplyTo":"487C5A2D.3000707@op5.se","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-15T23:38:51Z","receivedAt":"2008-07-15T23:38:51Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andreas Ericsson wrote:\n> I beat you to it ;-) This works just fine for me regardless of whether\n> or not I have a colon in COMP_WORDBREAKS.\n...\n> Subject: git-completion.bash: Handle \"rev:path\" completion properly\n...\n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index d268e6f..e138022 100755\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -293,7 +293,11 @@ __git_complete_file ()\n> \t\t*)\n> \t\t\tls=\"$ref\"\n> \t\t\t;;\n> -\t esac\n> +\t\tesac\n> +\t\t# When completing something like 'rev:path', bash behaves\n> +\t\t# differently whether or not COMP_WORDBREAKS contains a\n> +\t\t# colon or not. This lets it handle both cases\n> +\t\ttest \"${COMP_WORDBREAKS//:}\" = \"$COMP_WORDBREAKS\" && pfx=\"$ref:$pfx\"\n> \t\tCOMPREPLY=($(compgen -P \"$pfx\" \\\n> \t\t\t-W \"$(git --git-dir=\"$(__gitdir)\" ls-tree \"$ls\" \\\n> \t\t\t\t| sed '/^100... blob /s,^.*\t,,\n\nYea, I did more or less the same thing in my patch, but I also\nhandled this fix in git-fetch and git-push. The : is also used\nthere in a refspec and we support completion the right side of the\n: in both cases (and yes, on git-push that can be slow as we do\nnetwork IO, possibly over SSH).\n\nSo I'm in favor of my patch over yours, but only because of\nthe fetch and push fixes as well.\n\n-- \nShawn.\n"},{"id":"83485","messageId":"487DA138.8040004@op5.se","threadId":"14437","inReplyTo":"20080715233851.GA23672@spearce.org","subject":"Re: [PATCH] bash completion: Fix the . -> .. revision range completion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-07-16T07:20:24Z","receivedAt":"2008-07-16T07:20:24Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> Andreas Ericsson wrote:\n>> I beat you to it ;-) This works just fine for me regardless of whether\n>> or not I have a colon in COMP_WORDBREAKS.\n> ...\n>> Subject: git-completion.bash: Handle \"rev:path\" completion properly\n> ...\n>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n>> index d268e6f..e138022 100755\n>> --- a/contrib/completion/git-completion.bash\n>> +++ b/contrib/completion/git-completion.bash\n>> @@ -293,7 +293,11 @@ __git_complete_file ()\n>> \t\t*)\n>> \t\t\tls=\"$ref\"\n>> \t\t\t;;\n>> -\t esac\n>> +\t\tesac\n>> +\t\t# When completing something like 'rev:path', bash behaves\n>> +\t\t# differently whether or not COMP_WORDBREAKS contains a\n>> +\t\t# colon or not. This lets it handle both cases\n>> +\t\ttest \"${COMP_WORDBREAKS//:}\" = \"$COMP_WORDBREAKS\" && pfx=\"$ref:$pfx\"\n>> \t\tCOMPREPLY=($(compgen -P \"$pfx\" \\\n>> \t\t\t-W \"$(git --git-dir=\"$(__gitdir)\" ls-tree \"$ls\" \\\n>> \t\t\t\t| sed '/^100... blob /s,^.*\t,,\n> \n> Yea, I did more or less the same thing in my patch, but I also\n> handled this fix in git-fetch and git-push. The : is also used\n> there in a refspec and we support completion the right side of the\n> : in both cases (and yes, on git-push that can be slow as we do\n> network IO, possibly over SSH).\n> \n> So I'm in favor of my patch over yours, but only because of\n> the fetch and push fixes as well.\n> \n\nI agree, although I'd rather not have seen the case statement in\nyours. It's bash completion after all, so no need to be \"portably\nfast\" ;-)\n\nI don't care that much though so long as it gets fixed.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}