{"thread":{"id":"38883","subject":"Re: bug in bash completion for git-branch --set-upstream-to on OSX","startedAt":"2015-03-22T11:06:12Z","lastAt":"2015-03-23T14:42:20Z","messageCount":3,"participants":["SZEDER Gábor","Jason Karns"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"258289","messageId":"20150322120612.Horde.LAxCkP-VMKE3Ur7ZXII3Hg1@webmail.informatik.kit.edu","threadId":"38883","inReplyTo":null,"subject":"Re: bug in bash completion for git-branch --set-upstream-to on OSX","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2015-03-22T11:06:12Z","receivedAt":"2015-03-22T11:06:12Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"\nHi,\n\nQuoting Jason Karns <karns.17@gmail.com>:\n\n> There appears to be a bug in the bash completion for git-branch when\n> attempting to complete the remote ref argument for --set-upstream-to=\n>\n> When:\n>\n> $ git branch --set-upstream-to=origin/mast<TAB>\n>\n> I would expect it to complete to:\n>\n> $ git branch --set-upstream-to=origin/master\n>\n> However, the completion for --set-upstream-to= completes the ref\n> correctly, but completely wipes the --set-upstream option; resulting\n> in:\n>\n> $ git branch origin/master\n\nStrange.\n\nThe code in question\n\n    case \"$cur\" in\n    --set-upstream-to=*)\n            __gitcomp \"$(__git_refs)\" \"\" \"${cur##--set-upstream-to=}\"\n            ;;\n\nlooks unsuspicious, this is the \"standard\" way to complete\n'--option=<TAB>' (except that we should use __gitcomp_nl() for  \ncompleting refs, but that should have no effect on this issue).  Does  \nthe same issue affect other 'git cmd --option=<TAB>' completions as  \nwell, e.g. 'git log --date=<TAB>' or 'git commit --reuse-message=<TAB>'?\n\nWe had a similar issue with ':' on the command line a looong while\nago, see v1.5.6.4~9^2 (bash completion: Resolve git show ref:path<tab>\nlosing ref: portion, 2008-07-15).  Maybe we are dealing with the same  \nissue here, just a different character?\n\nWhat does\n\n    printf \"$COMP_WORDBREAKS\" |tr ' \\t\\n' STN\n\nprint out?  Is the '=' missing, perhaps?  If that's indeed the case,\ndoes adding it back (COMP_WORDBREAKS=\"$COMP_WORDBREAKS\"=) fix the issue?\n\nGábor\n"},{"id":"258361","messageId":"CAKNmmv2ap+svVJQHBjNzdcNuc42Urbt6uuBVRjfUMveb98sRHQ@mail.gmail.com","threadId":"38883","inReplyTo":"20150322120612.Horde.LAxCkP-VMKE3Ur7ZXII3Hg1@webmail.informatik.kit.edu","subject":"Re: bug in bash completion for git-branch --set-upstream-to on OSX","fromName":"Jason Karns","fromEmail":"karns.17@gmail.com","sentAt":"2015-03-23T13:45:16Z","receivedAt":"2015-03-23T13:45:16Z","isPatch":false,"sender":{"key":"karns.17@gmail.com","avatar":"https://gravatar.com/avatar/d7d24352c316abc20ea60ad9940f03f2a3523b7f8ca7b979017c5175b8d2307d?d=mp&s=160"},"body":"On Sun, Mar 22, 2015 at 7:06 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:\n>\n> Hi,\n>\n> Quoting Jason Karns <karns.17@gmail.com>:\n>\n>> There appears to be a bug in the bash completion for git-branch when\n>> attempting to complete the remote ref argument for --set-upstream-to=\n>>\n>> When:\n>>\n>> $ git branch --set-upstream-to=origin/mast<TAB>\n>>\n>> I would expect it to complete to:\n>>\n>> $ git branch --set-upstream-to=origin/master\n>>\n>> However, the completion for --set-upstream-to= completes the ref\n>> correctly, but completely wipes the --set-upstream option; resulting\n>> in:\n>>\n>> $ git branch origin/master\n>\n>\n> Strange.\n>\n> The code in question\n>\n>    case \"$cur\" in\n>    --set-upstream-to=*)\n>            __gitcomp \"$(__git_refs)\" \"\" \"${cur##--set-upstream-to=}\"\n>            ;;\n>\n> looks unsuspicious, this is the \"standard\" way to complete\n> '--option=<TAB>' (except that we should use __gitcomp_nl() for completing\n> refs, but that should have no effect on this issue).  Does the same issue\n> affect other 'git cmd --option=<TAB>' completions as well, e.g. 'git log\n> --date=<TAB>' or 'git commit --reuse-message=<TAB>'?\n\nYep, same buggy behavior.\n\n>\n> We had a similar issue with ':' on the command line a looong while\n> ago, see v1.5.6.4~9^2 (bash completion: Resolve git show ref:path<tab>\n> losing ref: portion, 2008-07-15).  Maybe we are dealing with the same issue\n> here, just a different character?\n>\n> What does\n>\n>    printf \"$COMP_WORDBREAKS\" |tr ' \\t\\n' STN\n>\n> print out?  Is the '=' missing, perhaps?  If that's indeed the case,\n> does adding it back (COMP_WORDBREAKS=\"$COMP_WORDBREAKS\"=) fix the issue?\n\nAdding it back in did indeed fix the issue. Now I get to track down\nwho/why `=` isn't present in COMP_WORDBREAKS.\n\nThanks!\n\n>\n> Gábor\n>\n\nJason\n"},{"id":"258364","messageId":"CAKNmmv3wpaECBbj8atA1s6hPzBvSMvfc=kkDTgbim4ufKVQuLg@mail.gmail.com","threadId":"38883","inReplyTo":"CAKNmmv2ap+svVJQHBjNzdcNuc42Urbt6uuBVRjfUMveb98sRHQ@mail.gmail.com","subject":"Re: bug in bash completion for git-branch --set-upstream-to on OSX","fromName":"Jason Karns","fromEmail":"karns.17@gmail.com","sentAt":"2015-03-23T14:42:20Z","receivedAt":"2015-03-23T14:42:20Z","isPatch":false,"sender":{"key":"karns.17@gmail.com","avatar":"https://gravatar.com/avatar/d7d24352c316abc20ea60ad9940f03f2a3523b7f8ca7b979017c5175b8d2307d?d=mp&s=160"},"body":"For those curious, the source of the broken behavior is npm's\ncompletion script. It is modifying COMP_WORDBREAKS. There are two open\nissues against npm for this bug.\n\nhttps://github.com/npm/npm/issues/4530\nhttps://github.com/npm/npm/issues/5820\n\nJason\n"}]}