{"thread":{"id":"12541","subject":"[PATCH] bash: __git_find_subcommand function","startedAt":"2008-03-06T14:58:32Z","lastAt":"2008-03-10T14:51:01Z","messageCount":3,"participants":["SZEDER Gábor","Shawn O. Pearce"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"71249","messageId":"1204815512-18128-1-git-send-email-szeder@ira.uka.de","threadId":"12541","inReplyTo":null,"subject":"[PATCH] bash: __git_find_subcommand function","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-03-06T14:58:32Z","receivedAt":"2008-03-06T14:58:32Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"This function takes one argument: a string containing all subcommands\nseparated by spaces. The function searches through the command line\nwhether a subcommand is already present. If a subcommand is found, it\nwill be printed to standard output.\n\nThis enables us to remove code duplications from completion\nfunctions for commands having subcommands.\n\nSigned-off-by: SZEDER Gábor \n---\nThis function does not return the index of the subcommand found on the\ncommand line, which was in the $c variable previously. However, $c was\nonly used in if statements, like:\n\tif [ $c -eq $COMP_CWORD -a -z \"$command\" ]; then\n\t\t__gitcomp \"cmd1 cmd2 cmd3\"\n\tfi\nTo my understanding the only(?) purpose of those if statements was to\nprevent subcommands appearing again on the list of possible completions,\nwhen there was one already on the command line. But [ -z $command ] is\nsufficient to detect those cases, so we can actually omit\n[ $c -eq $COMP_CWORD ]. Is it right, or am I missing something?\n\nNote, that some of the patches I sent out yesterday are in conflict with\nthese changes, namely:\n* [PATCH 1/2] bash: add missing 'git stash save' subcommand\n is in conflict,\n* [PATCH 2/2] bash: complete 'git stash' subcommands only once\n should be dropped,\n* [PATCH 1/2] bash: add 'git svn' subcommands\n should be updated, and\n* [PATCH 2/2] bash: add 'git svn' options\n should be updated (depends on the previous one).\nI think that if this patch will get merged, then it should be merged\nbefore those mentioned above. It just doesn't make much sense e.g. to\nmerge 'complete 'git stash' subcommands only once' and then basically\nrevert it. In this case, of course, I will send the updated patches.\n\n contrib/completion/git-completion.bash | 70 ++++++++++++++------------------\n 1 files changed, 31 insertions(+), 39 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 49e6df0..f9e29be 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -420,6 +420,22 @@ __git_aliased_command ()\n \tdone\n }\n \n+__git_find_subcommand ()\n+{\n+\tlocal word subcommand c=1\n+\n+\twhile [ $c -lt $COMP_CWORD ]; do\n+\t\tword=\"${COMP_WORDS[c]}\"\n+\t\tfor subcommand in $1; do\n+\t\t\tif [ \"$subcommand\" = \"$word\" ]; then\n+\t\t\t\techo \"$subcommand\"\n+\t\t\t\treturn\n+\t\t\tfi\n+\t\tdone\n+\t\tc=$((++c))\n+\tdone\n+}\n+\n __git_whitespacelist=\"nowarn warn error error-all strip\"\n \n _git_am ()\n@@ -477,24 +493,13 @@ _git_add ()\n \n _git_bisect ()\n {\n-\tlocal i c=1 command\n-\twhile [ $c -lt $COMP_CWORD ]; do\n-\t\ti=\"${COMP_WORDS[c]}\"\n-\t\tcase \"$i\" in\n-\t\tstart|bad|good|reset|visualize|replay|log)\n-\t\t\tcommand=\"$i\"\n-\t\t\tbreak\n-\t\t\t;;\n-\t\tesac\n-\t\tc=$((++c))\n-\tdone\n-\n-\tif [ $c -eq $COMP_CWORD -a -z \"$command\" ]; then\n-\t\t__gitcomp \"start bad good reset visualize replay log\"\n+\tlocal subcommands=\"start bad good reset visualize replay log\"\n+\tlocal subcommand=\"$(__git_find_subcommand \"$subcommands\")\"\n+\tif [ -z \"$subcommand\" ]; then\n \t\treturn\n \tfi\n \n-\tcase \"$command\" in\n+\tcase \"$subcommand\" in\n \tbad|good|reset)\n \t\t__gitcomp \"$(__git_refs)\"\n \t\t;;\n@@ -1025,21 +1030,13 @@ _git_config ()\n \n _git_remote ()\n {\n-\tlocal i c=1 command\n-\twhile [ $c -lt $COMP_CWORD ]; do\n-\t\ti=\"${COMP_WORDS[c]}\"\n-\t\tcase \"$i\" in\n-\t\tadd|rm|show|prune|update) command=\"$i\"; break ;;\n-\t\tesac\n-\t\tc=$((++c))\n-\tdone\n-\n-\tif [ $c -eq $COMP_CWORD -a -z \"$command\" ]; then\n-\t\t__gitcomp \"add rm show prune update\"\n+\tlocal subcommands=\"add rm show prune update\"\n+\tlocal subcommand=\"$(__git_find_subcommand \"$subcommands\")\"\n+\tif [ -z \"$subcommand\" ]; then\n \t\treturn\n \tfi\n \n-\tcase \"$command\" in\n+\tcase \"$subcommand\" in\n \trm|show|prune)\n \t\t__gitcomp \"$(__git_remotes)\"\n \t\t;;\n@@ -1113,28 +1110,23 @@ _git_show ()\n \n _git_stash ()\n {\n-\t__gitcomp 'list show apply clear'\n+\tlocal subcommands='list show apply clear'\n+\tif [ -z \"$(__git_find_subcommand \"$subcommands\")\" ]; then\n+\t\t__gitcomp \"$subcommands\"\n+\tfi\n }\n \n _git_submodule ()\n {\n-\tlocal i c=1 command\n-\twhile [ $c -lt $COMP_CWORD ]; do\n-\t\ti=\"${COMP_WORDS[c]}\"\n-\t\tcase \"$i\" in\n-\t\tadd|status|init|update) command=\"$i\"; break ;;\n-\t\tesac\n-\t\tc=$((++c))\n-\tdone\n"},{"id":"71400","messageId":"20080308022342.GY8410@spearce.org","threadId":"12541","inReplyTo":"1204815512-18128-1-git-send-email-szeder@ira.uka.de","subject":"Re: [PATCH] bash: __git_find_subcommand function","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-08T02:23:42Z","receivedAt":"2008-03-08T02:23:42Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"SZEDER Gbor wrote:\n> This enables us to remove code duplications from completion\n> functions for commands having subcommands.\n> \n> Signed-off-by: SZEDER Gábor \n> ---\n> This function does not return the index of the subcommand found on the\n> command line, which was in the $c variable previously. However, $c was\n> only used in if statements, like:\n> \tif [ $c -eq $COMP_CWORD -a -z \"$command\" ]; then\n> \t\t__gitcomp \"cmd1 cmd2 cmd3\"\n> \tfi\n> To my understanding the only(?) purpose of those if statements was to\n> prevent subcommands appearing again on the list of possible completions,\n> when there was one already on the command line. But [ -z $command ] is\n> sufficient to detect those cases, so we can actually omit\n> [ $c -eq $COMP_CWORD ]. Is it right, or am I missing something?\n\nYup, you understood it correctly. You found a cluster of \"copy and\npaste programming\" and I am happy to see it cleaned up. Thanks.\n\n-- \nShawn.\n"},{"id":"71589","messageId":"20080310145101.GA6468@neumann","threadId":"12541","inReplyTo":"20080308022342.GY8410@spearce.org","subject":"Re: [PATCH] bash: __git_find_subcommand function","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-03-10T14:51:01Z","receivedAt":"2008-03-10T14:51:01Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Mar 07, 2008 at 09:23:42PM -0500, Shawn O. Pearce wrote:\n> Yup, you understood it correctly. You found a cluster of \"copy and\n> paste programming\" and I am happy to see it cleaned up. Thanks.\nThanks. I will send out the updated patches soon.\n\nGábor\n"}]}