{"thread":{"id":"21165","subject":"[PATCHv2 2/2] completion: fix alias listings with newlines","startedAt":"2009-10-09T06:21:43Z","lastAt":"2009-10-09T14:29:50Z","messageCount":4,"participants":["Stephen Boyd","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"124425","messageId":"1255069304-8953-1-git-send-email-bebarino@gmail.com","threadId":"21165","inReplyTo":null,"subject":"[PATCH 1/2] completion: fix completion of git <TAB><TAB>","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-10-09T06:21:43Z","receivedAt":"2009-10-09T06:21:43Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"After commit 511a3fc (wrap git's main usage string., 2009-09-12), the\nbash completion for git commands includes COMMAND and [ARGS] when it\nshouldn't. Fix this by grepping more strictly for a line with git\ncommands. It's doubtful whether git will ever have commands starting\nwith anything besides numbers and letters so this should be fine. At\nleast by being stricter we'll know when we break the completion earlier.\n\nSigned-off-by: Stephen Boyd <bebarino@gmail.com>\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 88b1b3c..652a47c 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -496,7 +496,7 @@ __git_all_commands ()\n \t\treturn\n \tfi\n \tlocal i IFS=\" \"$'\\n'\n-\tfor i in $(git help -a|egrep '^ ')\n+\tfor i in $(git help -a|egrep '^  [a-zA-Z0-9]')\n \tdo\n \t\tcase $i in\n \t\t*--*)             : helper pattern;;\n-- \n1.6.5.rc3\n"},{"id":"124424","messageId":"1255069304-8953-2-git-send-email-bebarino@gmail.com","threadId":"21165","inReplyTo":"1255069304-8953-1-git-send-email-bebarino@gmail.com","subject":"[PATCHv2 2/2] completion: fix alias listings with newlines","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-10-09T06:21:44Z","receivedAt":"2009-10-09T06:21:44Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Aliases with newlines have been a problem since commit 56fc25f (Bash\ncompletion support for remotes in .git/config., 2006-11-05). The chance\nof the problem occurring has been slim at best, until commit 518ef8f\n(completion: Replace config --list with --get-regexp, 2009-09-11)\nremoved the case statement introduced by commit 56fc25f. Before removing\nthe case statement, most aliases with newlines would work unless they\nwere specially crafted as follows\n\n[alias]\n\tfoo = \"log -1 --pretty='format:%s\\nalias.error=broken'\"\n\nAfter removing the case statement, a more benign alias like\n\n[alias]\n\twhowhat = \"log -1 --pretty='format:%an <%ae>\\n%s'\"\n\twont-complete = ...\n\nwould cause the completion to break badly.\n\nFor now, revert the removal of the case statement until someone comes up\nwith a better way to get keys from git-config.\n\nSigned-off-by: Stephen Boyd <bebarino@gmail.com>\n---\n\nThis is an alternate fix to my previous 1/3 patch.\n\nHannes has convinced me to go this route. I don't really see a problem, it\nbasically reverts to broken behavior that nobody's complained about in 3\nyears. At least it's less broken?\n\n contrib/completion/git-completion.bash |    8 ++++++--\n 1 files changed, 6 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 652a47c..e482c8d 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -602,8 +602,12 @@ __git_aliases ()\n {\n \tlocal i IFS=$'\\n'\n \tfor i in $(git --git-dir=\"$(__gitdir)\" config --get-regexp \"alias\\..*\" 2>/dev/null); do\n-\t\ti=\"${i#alias.}\"\n-\t\techo \"${i/ */}\"\n+\t\tcase \"$i\" in\n+\t\talias.*)\n+\t\t\ti=\"${i#alias.}\"\n+\t\t\techo \"${i/ */}\"\n+\t\t\t;;\n+\t\tesac\n \tdone\n }\n \n-- \n1.6.5.rc3\n"},{"id":"124491","messageId":"20091009142654.GR9261@spearce.org","threadId":"21165","inReplyTo":"1255069304-8953-1-git-send-email-bebarino@gmail.com","subject":"Re: [PATCH 1/2] completion: fix completion of git <TAB><TAB>","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-10-09T14:26:54Z","receivedAt":"2009-10-09T14:26:54Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Stephen Boyd <bebarino@gmail.com> wrote:\n> After commit 511a3fc (wrap git's main usage string., 2009-09-12), the\n> bash completion for git commands includes COMMAND and [ARGS] when it\n> shouldn't. Fix this by grepping more strictly for a line with git\n> commands. It's doubtful whether git will ever have commands starting\n> with anything besides numbers and letters so this should be fine. At\n> least by being stricter we'll know when we break the completion earlier.\n> \n> Signed-off-by: Stephen Boyd <bebarino@gmail.com>\n\nAcked-by: Shawn O. Pearce <spearce@spearce.org>\n\n-- \nShawn.\n"},{"id":"124492","messageId":"20091009142950.GS9261@spearce.org","threadId":"21165","inReplyTo":"1255069304-8953-2-git-send-email-bebarino@gmail.com","subject":"Re: [PATCHv2 2/2] completion: fix alias listings with newlines","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-10-09T14:29:50Z","receivedAt":"2009-10-09T14:29:50Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Stephen Boyd <bebarino@gmail.com> wrote:\n> Aliases with newlines have been a problem since commit 56fc25f (Bash\n> completion support for remotes in .git/config., 2006-11-05). The chance\n> of the problem occurring has been slim at best, until commit 518ef8f\n> (completion: Replace config --list with --get-regexp, 2009-09-11)\n> removed the case statement introduced by commit 56fc25f. Before removing\n> the case statement, most aliases with newlines would work unless they\n> were specially crafted as follows\n...\n> Hannes has convinced me to go this route. I don't really see a problem, it\n> basically reverts to broken behavior that nobody's complained about in 3\n> years. At least it's less broken?\n\nYay.  Given that we have no better solution easily available,\nI like the idea of just reverting to the behavior we have had\nfor the past 3 years.  Thanks.\n\nAcked-by: Shawn O. Pearce <spearce@spearce.org>\n \n-- \nShawn.\n"}]}