{"thread":{"id":"44947","subject":"[PATCH 0/7] completion bash: add more options and commands","startedAt":"2017-01-22T22:57:51Z","lastAt":"2017-02-02T17:05:06Z","messageCount":41,"participants":["bitte.keine.werbung.einwerfen@googlemail.com","Johannes Sixt","Cornelius Weig","Junio C Hamano","Stefan Beller","Linus Torvalds","Eric Wong","Philip Oakley","cornelius.weig@tngtech.com","SZEDER Gábor"],"isPatch":true,"patchVersion":1,"patchTotal":7},"messages":[{"id":"309953","messageId":"20170122225724.19360-1-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":null,"subject":"[PATCH 0/7] completion bash: add more options and commands","fromName":"","fromEmail":"bitte.keine.werbung.einwerfen@googlemail.com","sentAt":"2017-01-22T22:57:17Z","receivedAt":"2017-01-22T22:57:51Z","isPatch":true,"sender":{"key":"bitte.keine.werbung.einwerfen@googlemail.com","avatar":null},"body":"From: Cornelius Weig \n\nThe cli interface for git has the greatest versatility of all git tools.\nIts productivity depends on how easy it is to type commands and to remember\noptions. The command line completion helps two-fold by easing input and\ndisplaying possible options.\n\nBash completion lacks support for several options and some useful commands.\nAlthough the selection of recognized options is always opinionated (e.g. the\ndocumentation for git-completion.bash says that 'common' long options are\nrecognized), I think that extending the cli completion will always increase the\nproductivity.\n\nTo that end, the following commits add completion support for several existing\noptions and subcommands. For every command all options that are mentioned in\nthe introduction of its man page should now be available for completion.\n\nCornelius Weig (7):\n completion: teach options to submodule subcommands\n completion: add subcommand completion for rerere\n completion: improve bash completion for git-add\n completion: teach ls-remote to complete options\n completion: teach replace to complete options\n completion: teach remote subcommands option completion\n completion: recognize more long-options\n\n contrib/completion/git-completion.bash | 132 +++++++++++++++++++++++++++------\n 1 file changed, 110 insertions(+), 22 deletions(-)\n\n-- \n2.10.2\n\n"},{"id":"309954","messageId":"20170122225724.19360-2-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"20170122225724.19360-1-cornelius.weig@tngtech.com","subject":"[PATCH 1/7] completion: teach options to submodule subcommands","fromName":"","fromEmail":"bitte.keine.werbung.einwerfen@googlemail.com","sentAt":"2017-01-22T22:57:18Z","receivedAt":"2017-01-22T22:57:54Z","isPatch":true,"sender":{"key":"bitte.keine.werbung.einwerfen@googlemail.com","avatar":null},"body":"From: Cornelius Weig \n\nThe subcommands of submodule have different long-options which command\nline users need to type in. Therefore, teach bash completion to support\nmost subcommand options for submodule.\n---\n contrib/completion/git-completion.bash | 32 ++++++++++++++++++++++++++++++--\n 1 file changed, 30 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 6721ff8..c54a557 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2556,10 +2556,11 @@ _git_submodule ()\n \t__git_has_doubledash && return\n \n \tlocal subcommands=\"add status init deinit update summary foreach sync\"\n-\tif [ -z \"$(__git_find_on_cmdline \"$subcommands\")\" ]; then\n+\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n+\tif [ -z \"$subcommand\" ]; then\n \t\tcase \"$cur\" in\n \t\t--*)\n-\t\t\t__gitcomp \"--quiet --cached\"\n+\t\t\t__gitcomp \"--quiet\"\n \t\t\t;;\n \t\t*)\n \t\t\t__gitcomp \"$subcommands\"\n@@ -2567,6 +2568,33 @@ _git_submodule ()\n \t\tesac\n \t\treturn\n \tfi\n+\n+\tcase \"$subcommand,$cur\" in\n+\tadd,--*)\n+\t\t__gitcomp \"--branch --force --name --reference --depth\"\n+\t\t;;\n+\tstatus,--*)\n+\t\t__gitcomp \"--cached --recursive\"\n+\t\t;;\n+\tdeinit,--*)\n+\t\t__gitcomp \"--force --all\"\n+\t\t;;\n+\tupdate,--*)\n+\t\t__gitcomp \"\n+\t\t\t--init --remote --no-fetch\n+\t\t\t--recommend-shallow --no-recommend-shallow\n+\t\t\t--force --rebase --merge --reference --depth --recursive --jobs\n+\t\t\"\n+\t\t;;\n+\tsummary,--*)\n+\t\t__gitcomp \"--cached --files --summary-limit\"\n+\t\t;;\n+\tforeach,--*|sync,--*)\n+\t\t__gitcomp \"--recursive\"\n+\t\t;;\n+\t*)\n+\t\t;;\n+\tesac\n }\n \n _git_svn ()\n-- \n2.10.2\n\n"},{"id":"309955","messageId":"20170122225724.19360-3-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"20170122225724.19360-1-cornelius.weig@tngtech.com","subject":"[PATCH 2/7] completion: add subcommand completion for rerere","fromName":"","fromEmail":"bitte.keine.werbung.einwerfen@googlemail.com","sentAt":"2017-01-22T22:57:19Z","receivedAt":"2017-01-22T22:57:57Z","isPatch":true,"sender":{"key":"bitte.keine.werbung.einwerfen@googlemail.com","avatar":null},"body":"From: Cornelius Weig \n\nManaging recorded resolutions requires command-line usage of git-rerere.\nAdded subcommand completion for rerere and path completion for its\nsubcommand forget.\n---\n contrib/completion/git-completion.bash | 11 +++++++++++\n 1 file changed, 11 insertions(+)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex c54a557..8329f09 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2401,6 +2401,17 @@ _git_replace ()\n \t__gitcomp_nl \"$(__git_refs)\"\n }\n \n+_git_rerere ()\n+{\n+\tlocal subcommands=\"clear forget diff remaining status gc\"\n+\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n+\tif test -z \"$subcommand\"\n+\tthen\n+\t\t__gitcomp \"$subcommands\"\n+\t\treturn\n+\tfi\n+}\n+\n _git_reset ()\n {\n \t__git_has_doubledash && return\n-- \n2.10.2\n\n"},{"id":"309956","messageId":"20170122225724.19360-5-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"20170122225724.19360-1-cornelius.weig@tngtech.com","subject":"[PATCH 4/7] completion: teach ls-remote to complete options","fromName":"","fromEmail":"bitte.keine.werbung.einwerfen@googlemail.com","sentAt":"2017-01-22T22:57:21Z","receivedAt":"2017-01-22T22:58:00Z","isPatch":true,"sender":{"key":"bitte.keine.werbung.einwerfen@googlemail.com","avatar":null},"body":"From: Cornelius Weig \n\nls-remote needs to complete remote names and its own options. In\naddition to the existing remote name completions, do also complete\nthe options --heads, --tags, --refs, and --get-url.\n---\n contrib/completion/git-completion.bash | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 652c7e2..36fe439 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1449,6 +1449,12 @@ _git_ls_files ()\n \n _git_ls_remote ()\n {\n+\tcase \"$cur\" in\n+\t--*)\n+\t\t__gitcomp \"--heads --tags --refs --get-url\"\n+\t\treturn\n+\t\t;;\n+\tesac\n \t__gitcomp_nl \"$(__git_remotes)\"\n }\n \n-- \n2.10.2\n\n"},{"id":"309957","messageId":"20170122225724.19360-8-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"20170122225724.19360-1-cornelius.weig@tngtech.com","subject":"[PATCH 7/7] completion: recognize more long-options","fromName":"","fromEmail":"bitte.keine.werbung.einwerfen@googlemail.com","sentAt":"2017-01-22T22:57:24Z","receivedAt":"2017-01-22T22:58:03Z","isPatch":true,"sender":{"key":"bitte.keine.werbung.einwerfen@googlemail.com","avatar":null},"body":"From: Cornelius Weig \n\nRecognize several new long-options for bash completion in the following\ncommands:\n\n - apply: --recount --directory= --unsafe-paths\n - archive: --prefix= --remote= --exec= --output\n - branch: --column --no-column --sort= --points-at\n - clone: --no-single-branch --shallow-submodules\n - commit: --patch --short --date --allow-empty\n - describe: --first-parent\n - fetch, pull: --unshallow --update-shallow\n - fsck: --name-objects\n - grep: --break --heading --show-function --function-context\n --untracked --no-index\n - mergetool: --prompt --no-prompt\n - reset: --merge --mixed --hard --soft --patch --keep\n - revert: --strategy= --strategy-option=\n - rm: --force\n - shortlog: --email\n - tag: --merged --no-merged --create-reflog\n---\n contrib/completion/git-completion.bash | 31 +++++++++++++++++++++----------\n 1 file changed, 21 insertions(+), 10 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 0e09519..87d3d2c 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -936,6 +936,7 @@ _git_apply ()\n \t\t\t--apply --no-add --exclude=\n \t\t\t--ignore-whitespace --ignore-space-change\n \t\t\t--whitespace= --inaccurate-eof --verbose\n+\t\t\t--recount --directory= --unsafe-paths\n \t\t\t\"\n \t\treturn\n \tesac\n@@ -974,7 +975,7 @@ _git_archive ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--format= --list --verbose\n-\t\t\t--prefix= --remote= --exec=\n+\t\t\t--prefix= --remote= --exec= --output\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -1029,6 +1030,7 @@ _git_branch ()\n \t\t\t--track --no-track --contains --merged --no-merged\n \t\t\t--set-upstream-to= --edit-description --list\n \t\t\t--unset-upstream --delete --move --remotes\n+\t\t\t--column --no-column --sort= --points-at\n \t\t\t\"\n \t\t;;\n \t*)\n@@ -1142,6 +1144,8 @@ _git_clone ()\n \t\t\t--single-branch\n \t\t\t--branch\n \t\t\t--recurse-submodules\n+\t\t\t--no-single-branch\n+\t\t\t--shallow-submodules\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -1183,6 +1187,7 @@ _git_commit ()\n \t\t\t--reset-author --file= --message= --template=\n \t\t\t--cleanup= --untracked-files --untracked-files=\n \t\t\t--verbose --quiet --fixup= --squash=\n+\t\t\t--patch --short --date --allow-empty\n \t\t\t\"\n \t\treturn\n \tesac\n@@ -1201,7 +1206,7 @@ _git_describe ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--all --tags --contains --abbrev= --candidates=\n-\t\t\t--exact-match --debug --long --match --always\n+\t\t\t--exact-match --debug --long --match --always --first-parent\n \t\t\t\"\n \t\treturn\n \tesac\n@@ -1284,6 +1289,7 @@ __git_fetch_recurse_submodules=\"yes on-demand no\"\n __git_fetch_options=\"\n \t--quiet --verbose --append --upload-pack --force --keep --depth=\n \t--tags --no-tags --all --prune --dry-run --recurse-submodules=\n+\t--unshallow --update-shallow\n \"\n \n _git_fetch ()\n@@ -1333,7 +1339,7 @@ _git_fsck ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--tags --root --unreachable --cache --no-reflogs --full\n-\t\t\t--strict --verbose --lost-found\n+\t\t\t--strict --verbose --lost-found --name-objects\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -1377,6 +1383,8 @@ _git_grep ()\n \t\t\t--max-depth\n \t\t\t--count\n \t\t\t--and --or --not --all-match\n+\t\t\t--break --heading --show-function --function-context\n+\t\t\t--untracked --no-index\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -1576,7 +1584,7 @@ _git_mergetool ()\n \t\treturn\n \t\t;;\n \t--*)\n-\t\t__gitcomp \"--tool=\"\n+\t\t__gitcomp \"--tool= --prompt --no-prompt\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2456,7 +2464,7 @@ _git_reset ()\n \n \tcase \"$cur\" in\n \t--*)\n-\t\t__gitcomp \"--merge --mixed --hard --soft --patch\"\n+\t\t__gitcomp \"--merge --mixed --hard --soft --patch --keep\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2472,7 +2480,10 @@ _git_revert ()\n \tfi\n \tcase \"$cur\" in\n \t--*)\n-\t\t__gitcomp \"--edit --mainline --no-edit --no-commit --signoff\"\n+\t\t__gitcomp \"\n+\t\t\t--edit --mainline --no-edit --no-commit --signoff\n+\t\t\t--strategy= --strategy-option=\n+\t\t\t\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2483,7 +2494,7 @@ _git_rm ()\n {\n \tcase \"$cur\" in\n \t--*)\n-\t\t__gitcomp \"--cached --dry-run --ignore-unmatch --quiet\"\n+\t\t__gitcomp \"--cached --dry-run --ignore-unmatch --quiet --force\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2500,7 +2511,7 @@ _git_shortlog ()\n \t\t__gitcomp \"\n \t\t\t$__git_log_common_options\n \t\t\t$__git_log_shortlog_options\n-\t\t\t--numbered --summary\n+\t\t\t--numbered --summary --email\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -2778,8 +2789,8 @@ _git_tag ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--list --delete --verify --annotate --message --file\n-\t\t\t--sign --cleanup --local-user --force --column --sort\n-\t\t\t--contains --points-at\n+\t\t\t--sign --cleanup --local-user --force --column --sort=\n+\t\t\t--contains --points-at --merged --no-merged --create-reflog\n \t\t\t\"\n \t\t;;\n \tesac\n-- \n2.10.2\n\n"},{"id":"309958","messageId":"20170122225724.19360-4-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"20170122225724.19360-1-cornelius.weig@tngtech.com","subject":"[PATCH 3/7] completion: improve bash completion for git-add","fromName":"","fromEmail":"bitte.keine.werbung.einwerfen@googlemail.com","sentAt":"2017-01-22T22:57:20Z","receivedAt":"2017-01-22T22:58:06Z","isPatch":true,"sender":{"key":"bitte.keine.werbung.einwerfen@googlemail.com","avatar":null},"body":"From: Cornelius Weig \n\nAdd some long-options for git-add and improve path completion when the\n--update flag is given.\n---\n contrib/completion/git-completion.bash | 10 +++++++---\n 1 file changed, 7 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 8329f09..652c7e2 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -947,13 +947,17 @@ _git_add ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--interactive --refresh --patch --update --dry-run\n-\t\t\t--ignore-errors --intent-to-add\n+\t\t\t--ignore-errors --intent-to-add --force --edit --chmod=\n \t\t\t\"\n \t\treturn\n \tesac\n \n-\t# XXX should we check for --update and --all options ?\n-\t__git_complete_index_file \"--others --modified --directory --no-empty-directory\"\n+\tlocal complete_opt=\"--others --modified --directory --no-empty-directory\"\n+\tif test -n \"$(__git_find_on_cmdline \"-u --update\")\"\n+\tthen\n+\t\tcomplete_opt=\"--modified\"\n+\tfi\n+\t__git_complete_index_file \"$complete_opt\"\n }\n \n _git_archive ()\n-- \n2.10.2\n\n"},{"id":"309959","messageId":"20170122225724.19360-6-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"20170122225724.19360-1-cornelius.weig@tngtech.com","subject":"[PATCH 5/7] completion: teach replace to complete options","fromName":"","fromEmail":"bitte.keine.werbung.einwerfen@googlemail.com","sentAt":"2017-01-22T22:57:22Z","receivedAt":"2017-01-22T22:58:09Z","isPatch":true,"sender":{"key":"bitte.keine.werbung.einwerfen@googlemail.com","avatar":null},"body":"From: Cornelius Weig \n\nGit-replace needs to complete references and its own options. In\naddition to the existing references completions, do also complete the\noptions --edit --graft --format= --list --delete.\n---\n contrib/completion/git-completion.bash | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 36fe439..e76cbd7 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2408,6 +2408,12 @@ _git_remote ()\n \n _git_replace ()\n {\n+\tcase \"$cur\" in\n+\t--*)\n+\t\t__gitcomp \"--edit --graft --format= --list --delete\"\n+\t\treturn\n+\t\t;;\n+\tesac\n \t__gitcomp_nl \"$(__git_refs)\"\n }\n \n-- \n2.10.2\n\n"},{"id":"309960","messageId":"20170122225724.19360-7-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"20170122225724.19360-1-cornelius.weig@tngtech.com","subject":"[PATCH 6/7] completion: teach remote subcommands option completion","fromName":"","fromEmail":"bitte.keine.werbung.einwerfen@googlemail.com","sentAt":"2017-01-22T22:57:23Z","receivedAt":"2017-01-22T22:58:12Z","isPatch":true,"sender":{"key":"bitte.keine.werbung.einwerfen@googlemail.com","avatar":null},"body":"From: Cornelius Weig \n\nGit-remote needs to complete remote names, its subcommands, and options\nthereof. In addition to the existing subcommand and remote name\ncompletion, do also complete the options\n\n - add: --track --master --fetch --tags --no-tags --mirror=\n - set-url: --push --add --delete\n - get-url: --push --all\n - prune: --dry-run\n---\n contrib/completion/git-completion.bash | 36 +++++++++++++++++++++++++++-------\n 1 file changed, 29 insertions(+), 7 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex e76cbd7..0e09519 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2384,24 +2384,46 @@ _git_config ()\n \n _git_remote ()\n {\n-\tlocal subcommands=\"add rename remove set-head set-branches set-url show prune update\"\n+\tlocal subcommands=\"\n+\t\tadd rename remove set-head set-branches\n+\t\tget-url set-url show prune update\n+\t\t\"\n \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n \tif [ -z \"$subcommand\" ]; then\n-\t\t__gitcomp \"$subcommands\"\n+\t\tcase \"$cur\" in\n+\t\t--*)\n+\t\t\t__gitcomp \"--verbose\"\n+\t\t\t;;\n+\t\t*)\n+\t\t\t__gitcomp \"$subcommands\"\n+\t\t\t;;\n+\t\tesac\n \t\treturn\n \tfi\n \n-\tcase \"$subcommand\" in\n-\trename|remove|set-url|show|prune)\n-\t\t__gitcomp_nl \"$(__git_remotes)\"\n+\tcase \"$subcommand,$cur\" in\n+\tadd,--*)\n+\t\t__gitcomp \"--track --master --fetch --tags --no-tags --mirror=\"\n \t\t;;\n-\tset-head|set-branches)\n+\tadd,*)\n+\t\t;;\n+\tset-head,*|set-branches,*)\n \t\t__git_complete_remote_or_refspec\n \t\t;;\n-\tupdate)\n+\tupdate,*)\n \t\t__gitcomp \"$(__git_get_config_variables \"remotes\")\"\n \t\t;;\n+\tset-url,--*)\n+\t\t__gitcomp \"--push --add --delete\"\n+\t\t;;\n+\tget-url,--*)\n+\t\t__gitcomp \"--push --all\"\n+\t\t;;\n+\tprune,--*)\n+\t\t__gitcomp \"--dry-run\"\n+\t\t;;\n \t*)\n+\t\t__gitcomp_nl \"$(__git_remotes)\"\n \t\t;;\n \tesac\n }\n-- \n2.10.2\n\n"},{"id":"310076","messageId":"74ecd09c-55da-3858-5187-52c286a6bf62@kdbg.org","threadId":"44947","inReplyTo":"20170122225724.19360-8-cornelius.weig@tngtech.com","subject":"Re: [PATCH 7/7] completion: recognize more long-options","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-01-24T07:15:56Z","receivedAt":"2017-01-24T07:16:05Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"If at all possible, please use your real email address as the From \naddress. It is pointless to hide behind a fake address because as Git \ncontributor you will have to reveal your identity anyway.\n\nPlease study item (5) \"Sign your work\" in \nDocumentation/SubmittingPatches and sign off your work.\n\nI'm by no means a bash completion expert, but I have a comment on this \npatch.\n\nAm 22.01.2017 um 23:57 schrieb bitte.keine.werbung.einwerfen@googlemail.com:\n> Recognize several new long-options for bash completion in the following\n> commands:\n\nAFAIR, it was a deliberate decision that potentially destructive command \nline options are not included in command completions. In the list given, \nI find these:\n\n> - apply: --unsafe-paths\n> - reset: --merge --mixed --hard --soft --patch --keep\n> - rm: --force\n\nAdditionally, these options are only for internal purposes, but I may be \nwrong:\n\n> - archive: --remote= --exec=\n\n-- Hannes\n\n"},{"id":"310077","messageId":"967937ff-e5ff-2515-2f50-80a96683c068@tngtech.com","threadId":"44947","inReplyTo":"74ecd09c-55da-3858-5187-52c286a6bf62@kdbg.org","subject":"Re: [PATCH 7/7] completion: recognize more long-options","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-01-24T08:14:25Z","receivedAt":"2017-01-24T08:21:10Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"On 01/24/2017 08:15 AM, Johannes Sixt wrote:\n> If at all possible, please use your real email address as the From\n> address. It is pointless to hide behind a fake address because as Git\n> contributor you will have to reveal your identity anyway.\n\nThese are both real addresses, but for send-mail I would not want to use\nmy work account. I hope this is not a problem.\n\n> Please study item (5) \"Sign your work\" in\n> Documentation/SubmittingPatches and sign off your work.\n\nI followed the recommendations to submitting work, and in the first\nround signing is discouraged.\n\n> AFAIR, it was a deliberate decision that potentially destructive command\n> line options are not included in command completions. In the list given,\n> I find these:\n>\n>> - reset: --merge --mixed --hard --soft --patch --keep\n\nMy bad, I only added --keep, which should be fine. As to these options\n\n>> - apply: --unsafe-paths\n>> - rm: --force\n\nlet's wait for further comments, but I won't cling to it.\n\n> Additionally, these options are only for internal purposes, but I may be\n> wrong:\n>\n>> - archive: --remote= --exec=\n\nThese may in fact be too exotic and just clutter the command line. Best\nthey are removed.\n\n-- Cornelius\n"},{"id":"310120","messageId":"xmqqd1fcca8n.fsf@gitster.mtv.corp.google.com","threadId":"44947","inReplyTo":"967937ff-e5ff-2515-2f50-80a96683c068@tngtech.com","subject":"Re: [PATCH 7/7] completion: recognize more long-options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-24T23:24:24Z","receivedAt":"2017-01-24T23:24:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Cornelius Weig writes:\n\n>> Please study item (5) \"Sign your work\" in\n>> Documentation/SubmittingPatches and sign off your work.\n>\n> I followed the recommendations to submitting work, and in the first\n> round signing is discouraged.\n\nJust this point. You found a bug in our documentation if that is\nthe case; it should not be giving that impression to you. \n\n"},{"id":"310121","messageId":"a921bc92-4f20-3284-6577-344470a60c6f@tngtech.com","threadId":"44947","inReplyTo":"xmqqd1fcca8n.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 7/7] completion: recognize more long-options","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-01-24T23:33:46Z","receivedAt":"2017-01-24T23:33:55Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"On 01/25/2017 12:24 AM, Junio C Hamano wrote:\n> Cornelius Weig writes:\n> \n>>> Please study item (5) \"Sign your work\" in\n>>> Documentation/SubmittingPatches and sign off your work.\n>>\n>> I followed the recommendations to submitting work, and in the first\n>> round signing is discouraged.\n> \n> Just this point. You found a bug in our documentation if that is\n> the case; it should not be giving that impression to you. \n> \n\nWell, I am referring to par. (4) of Documentation/SubmittingPatches\n(emphasis mine):\n\n<<<<<<<<<<<<<<\n*Do not PGP sign your patch, at least for now*. Most likely, your\nmaintainer or other people on the list would not have your PGP\nkey and would not bother obtaining it anyway. Your patch is not\njudged by who you are; a good patch from an unknown origin has a\nfar better chance of being accepted than a patch from a known,\nrespected origin that is done poorly or does incorrect things.\n>>>>>>>>>>>>>>\n\nIf first submissions should be signed as well, then I find this quite\nmisleading.\n\n"},{"id":"310122","messageId":"CAGZ79ka0PSb9L71tkiacZS+FH=YbUBrQr6a5UQu7ochpihRqEQ@mail.gmail.com","threadId":"44947","inReplyTo":"a921bc92-4f20-3284-6577-344470a60c6f@tngtech.com","subject":"Re: [PATCH 7/7] completion: recognize more long-options","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-24T23:43:21Z","receivedAt":"2017-01-24T23:43:27Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Jan 24, 2017 at 3:33 PM, Cornelius Weig\n wrote:\n> On 01/25/2017 12:24 AM, Junio C Hamano wrote:\n>> Cornelius Weig writes:\n>>\n>>>> Please study item (5) \"Sign your work\" in\n>>>> Documentation/SubmittingPatches and sign off your work.\n>>>\n>>> I followed the recommendations to submitting work, and in the first\n>>> round signing is discouraged.\n>>\n>> Just this point. You found a bug in our documentation if that is\n>> the case; it should not be giving that impression to you.\n>>\n>\n> Well, I am referring to par. (4) of Documentation/SubmittingPatches\n> (emphasis mine):\n>\n> <<<<<<<<<<<<<<\n> *Do not PGP sign your patch, at least for now*. Most likely, your\n> maintainer or other people on the list would not have your PGP\n> key and would not bother obtaining it anyway. Your patch is not\n> judged by who you are; a good patch from an unknown origin has a\n> far better chance of being accepted than a patch from a known,\n> respected origin that is done poorly or does incorrect things.\n>>>>>>>>>>>>>>>\n>\n> If first submissions should be signed as well, then I find this quite\n> misleading.\n>\n\nPlease read on; While this part addresses PGP signing,\nwhich is discouraged at any round,\nlater on we talk about another type of signing.\n(not cryptographic strong signing, but signing the intent;)\nthe DCO in the commit message.\n\nSo no PGP signing (in any round of the patch).\n\nBut DCO signed (in anything that you deem useful for the\nproject and that you are allowed to contribute)\n"},{"id":"310128","messageId":"923cd4e4-5c9c-4eaf-0fea-6deff6875b88@tngtech.com","threadId":"44947","inReplyTo":"CAGZ79ka0PSb9L71tkiacZS+FH=YbUBrQr6a5UQu7ochpihRqEQ@mail.gmail.com","subject":"Re: [PATCH 7/7] completion: recognize more long-options","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-01-25T00:11:51Z","receivedAt":"2017-01-25T00:21:07Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"\n\nOn 01/25/2017 12:43 AM, Stefan Beller wrote:\n> On Tue, Jan 24, 2017 at 3:33 PM, Cornelius Weig\n> wrote:\n>> On 01/25/2017 12:24 AM, Junio C Hamano wrote:\n>>> Cornelius Weig writes:\n>>>\n>>>>> Please study item (5) \"Sign your work\" in\n>>>>> Documentation/SubmittingPatches and sign off your work.\n>>>>\n>>>> I followed the recommendations to submitting work, and in the first\n>>>> round signing is discouraged.\n>>>\n>>> Just this point. You found a bug in our documentation if that is\n>>> the case; it should not be giving that impression to you.\n>>>\n>>\n>> Well, I am referring to par. (4) of Documentation/SubmittingPatches\n>> (emphasis mine):\n>>\n>> <<<<<<<<<<<<<<\n>> *Do not PGP sign your patch, at least for now*. Most likely, your\n>> maintainer or other people on the list would not have your PGP\n>> key and would not bother obtaining it anyway. Your patch is not\n>> judged by who you are; a good patch from an unknown origin has a\n>> far better chance of being accepted than a patch from a known,\n>> respected origin that is done poorly or does incorrect things.\n>> <<<<<<<<<<<<<<\n>>\n>> If first submissions should be signed as well, then I find this quite\n>> misleading.\n>>\n> \n> Please read on; While this part addresses PGP signing,\n> which is discouraged at any round,\n> later on we talk about another type of signing.\n> (not cryptographic strong signing, but signing the intent;)\n> the DCO in the commit message.\n> \n> So no PGP signing (in any round of the patch).\n> \n> But DCO signed (in anything that you deem useful for the\n> project and that you are allowed to contribute)\n> \n\nRight, it's crystal clear now. What confused me was the combination of\n\n> Do not PGP sign your patch, at least *for now*. (...)\n\nand then the section with heading\n\n> (5) *Sign* your work\n\nSo I didn't even bother to read (5) because I deemed it irrelevant. I\nthink if it had said `(5) *Certify* your work` this would not have happened.\n"},{"id":"310129","messageId":"20170125002116.22111-1-sbeller@google.com","threadId":"44947","inReplyTo":"923cd4e4-5c9c-4eaf-0fea-6deff6875b88@tngtech.com","subject":"","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-25T00:21:16Z","receivedAt":"2017-01-25T00:21:23Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"\n>\n>> Do not PGP sign your patch, at least *for now*. (...)\n>\n\nAnd maybe these 2 small words are the bug in the documentation?\nShall we drop the \"at least for now\" part, like so:\n\n---8<---\nFrom 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001\nFrom: Stefan Beller \nDate: Tue, 24 Jan 2017 16:19:13 -0800\nSubject: [PATCH] SubmittingPatches: drop temporal reference for PGP signing\n\nSigned-off-by: Stefan Beller \n---\n Documentation/SubmittingPatches | 12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 08352deaae..28da4ad2d4 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -216,12 +216,12 @@ that it will be postponed.\n Exception: If your mailer is mangling patches then someone may ask\n you to re-send them using MIME, that is OK.\n \n-Do not PGP sign your patch, at least for now. Most likely, your\n-maintainer or other people on the list would not have your PGP\n-key and would not bother obtaining it anyway. Your patch is not\n-judged by who you are; a good patch from an unknown origin has a\n-far better chance of being accepted than a patch from a known,\n-respected origin that is done poorly or does incorrect things.\n+Do not PGP sign your patch. Most likely, your maintainer or other\n+people on the list would not have your PGP key and would not bother\n+obtaining it anyway. Your patch is not judged by who you are; a good\n+patch from an unknown origin has a far better chance of being accepted\n+than a patch from a known, respected origin that is done poorly or\n+does incorrect things.\n \n If you really really really really want to do a PGP signed\n patch, format it as \"multipart/signed\", not a text/plain message\n-- \n2.11.0.495.g04f60290a0.dirty\n\n"},{"id":"310130","messageId":"ec2a198e-edf5-68a1-523c-12a9d1333c58@tngtech.com","threadId":"44947","inReplyTo":"20170125002116.22111-1-sbeller@google.com","subject":"Re:","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-01-25T00:43:39Z","receivedAt":"2017-01-25T00:43:49Z","isPatch":false,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"On 01/25/2017 01:21 AM, Stefan Beller wrote:\n>>\n>>> Do not PGP sign your patch, at least *for now*. (...)\n>>\n> \n> And maybe these 2 small words are the bug in the documentation?\n> Shall we drop the \"at least for now\" part, like so:\n> \n> ---8<---\n> From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001\n> From: Stefan Beller \n> Date: Tue, 24 Jan 2017 16:19:13 -0800\n> Subject: [PATCH] SubmittingPatches: drop temporal reference for PGP signing\n> \n> Signed-off-by: Stefan Beller \n> ---\n> Documentation/SubmittingPatches | 12 ++++++------\n> 1 file changed, 6 insertions(+), 6 deletions(-)\n> \n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index 08352deaae..28da4ad2d4 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -216,12 +216,12 @@ that it will be postponed.\n> Exception: If your mailer is mangling patches then someone may ask\n> you to re-send them using MIME, that is OK.\n> \n> -Do not PGP sign your patch, at least for now. Most likely, your\n> -maintainer or other people on the list would not have your PGP\n> -key and would not bother obtaining it anyway. Your patch is not\n> -judged by who you are; a good patch from an unknown origin has a\n> -far better chance of being accepted than a patch from a known,\n> -respected origin that is done poorly or does incorrect things.\n> +Do not PGP sign your patch. Most likely, your maintainer or other\n> +people on the list would not have your PGP key and would not bother\n> +obtaining it anyway. Your patch is not judged by who you are; a good\n> +patch from an unknown origin has a far better chance of being accepted\n> +than a patch from a known, respected origin that is done poorly or\n> +does incorrect things.\n> \n> If you really really really really want to do a PGP signed\n> patch, format it as \"multipart/signed\", not a text/plain message\n> \n\nIt definitely is an improvement. Though it would still leave me puzzled\nwhen finding a section about signing just below.\n\nIs changing heading (5) too big a change? Like so:\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 08352de..71898dc 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -246,7 +246,7 @@ patch.\n *2* The mailing list: git@vger.kernel.org\n \n \n-(5) Sign your work\n+(5) Certify your work by signing off.\n \n To improve tracking of who did what, we've borrowed the\n \"sign-off\" procedure from the Linux kernel project on patches\n"},{"id":"310132","messageId":"CAGZ79ka2b4BxYXEou6QrvxwbTjTdd7BRqhA1ZEw8e-gjB3cDDQ@mail.gmail.com","threadId":"44947","inReplyTo":"ec2a198e-edf5-68a1-523c-12a9d1333c58@tngtech.com","subject":"Re:","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-25T00:52:11Z","receivedAt":"2017-01-25T00:52:17Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Jan 24, 2017 at 4:43 PM, Cornelius Weig\n wrote:\n\n> -(5) Sign your work\n> +(5) Certify your work by signing off.\n\nThat sounds better than what I proposed.\n\nThanks,\nStefan\n"},{"id":"310133","messageId":"CA+55aFx_W500Ct6HuG18owG37FviirjsrJ_4zZpRcDD-0tmpFg@mail.gmail.com","threadId":"44947","inReplyTo":"20170125002116.22111-1-sbeller@google.com","subject":"Re:","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2017-01-25T00:54:00Z","receivedAt":"2017-01-25T00:54:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller wrote:\n>\n> +Do not PGP sign your patch. Most likely, your maintainer or other\n> +people on the list would not have your PGP key and would not bother\n> +obtaining it anyway.\n\nI think even that could be further simplified - by just removing all\ncomments about pgp email\n\nBecause it's not that the PGP keys would be hard to get, it's that\nPGP-signed email is an abject failure, and nobody sane does it.\n\nGoogle for \"phil zimmerman doesn't use pgp email\".\n\nIt's dead. So I'm not sure it's worth mentioning at all.\n\nYou might as well talk about how you shouldn't use EBCDIC encoding for\nyour patches, or about why git assumes that an email address has an\n'@' sign in it, instead of being an UUCP bang path address.\n\n Linus\n"},{"id":"310134","messageId":"20170125013233.GA16463@starla","threadId":"44947","inReplyTo":"CA+55aFx_W500Ct6HuG18owG37FviirjsrJ_4zZpRcDD-0tmpFg@mail.gmail.com","subject":"Re:","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2017-01-25T01:32:33Z","receivedAt":"2017-01-25T01:32:41Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Linus Torvalds wrote:\n> On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller wrote:\n> >\n> > +Do not PGP sign your patch. Most likely, your maintainer or other\n> > +people on the list would not have your PGP key and would not bother\n> > +obtaining it anyway.\n> \n> I think even that could be further simplified - by just removing all\n> comments about pgp email\n> \n> Because it's not that the PGP keys would be hard to get, it's that\n> PGP-signed email is an abject failure, and nobody sane does it.\n> \n> Google for \"phil zimmerman doesn't use pgp email\".\n> \n> It's dead. So I'm not sure it's worth mentioning at all.\n\nI disagree, we still see it, and Debian still advocates it.\nIn fact, we may also want to mention S/MIME in the same breath:\n\n https://public-inbox.org/git/20170110004031.57985-2-hansenr@google.com/\n\nRichard's more recent mails seem to indicate he's reformed :)\n"},{"id":"310141","messageId":"33E354BCDB9A4192B69B9B399381659E@PhilipOakley","threadId":"44947","inReplyTo":"20170125002116.22111-1-sbeller@google.com","subject":"Re: SubmittingPatches: drop temporal reference for PGP signing","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-01-25T06:55:09Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Stefan Beller\" \n>>\n>>> Do not PGP sign your patch, at least *for now*. (...)\n>>\n>\n> And maybe these 2 small words are the bug in the documentation?\n> Shall we drop the \"at least for now\" part, like so:\n>\n> ---8<---\n> From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001\n> From: Stefan Beller \n> Date: Tue, 24 Jan 2017 16:19:13 -0800\n> Subject: [PATCH] SubmittingPatches: drop temporal reference for PGP \n> signing\n>\n> Signed-off-by: Stefan Beller \n> ---\n> Documentation/SubmittingPatches | 12 ++++++------\n> 1 file changed, 6 insertions(+), 6 deletions(-)\n>\n> diff --git a/Documentation/SubmittingPatches \n> b/Documentation/SubmittingPatches\n> index 08352deaae..28da4ad2d4 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -216,12 +216,12 @@ that it will be postponed.\n> Exception: If your mailer is mangling patches then someone may ask\n> you to re-send them using MIME, that is OK.\n>\n> -Do not PGP sign your patch, at least for now. Most likely, your\n> -maintainer or other people on the list would not have your PGP\n> -key and would not bother obtaining it anyway. Your patch is not\n> -judged by who you are; a good patch from an unknown origin has a\n> -far better chance of being accepted than a patch from a known,\n> -respected origin that is done poorly or does incorrect things.\n> +Do not PGP sign your patch. Most likely, your maintainer or other\n> +people on the list would not have your PGP key and would not bother\n> +obtaining it anyway. Your patch is not judged by who you are; a good\n> +patch from an unknown origin has a far better chance of being accepted\n> +than a patch from a known, respected origin that is done poorly or\n> +does incorrect things.\n\nWouldn't this also benefit from a forward reference to the section 5 on the \nDOC signining? This would avoid Cornelius's case where he felt that section \n5 no longer applied.\n\n> If you really really really really want to do a PGP signed\n> patch, format it as \"multipart/signed\", not a text/plain message\n> -- \n> 2.11.0.495.g04f60290a0.dirty\n--\nPhilip \n\n"},{"id":"310246","messageId":"CAGZ79kaRdtKD7DNJRWXsyg07GbTM4OsKUmHHcFczEMJA1YK2KA@mail.gmail.com","threadId":"44947","inReplyTo":"33E354BCDB9A4192B69B9B399381659E@PhilipOakley","subject":"Re: SubmittingPatches: drop temporal reference for PGP signing","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-25T22:38:23Z","receivedAt":"2017-01-25T22:38:28Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Jan 24, 2017 at 10:54 PM, Philip Oakley wrote:\n>> -Do not PGP sign your patch, at least for now. Most likely, your\n>> -maintainer or other people on the list would not have your PGP\n>> -key and would not bother obtaining it anyway. Your patch is not\n>> -judged by who you are; a good patch from an unknown origin has a\n>> -far better chance of being accepted than a patch from a known,\n>> -respected origin that is done poorly or does incorrect things.\n>> +Do not PGP sign your patch. Most likely, your maintainer or other\n>> +people on the list would not have your PGP key and would not bother\n>> +obtaining it anyway. Your patch is not judged by who you are; a good\n>> +patch from an unknown origin has a far better chance of being accepted\n>> +than a patch from a known, respected origin that is done poorly or\n>> +does incorrect things.\n>\n>\n> Wouldn't this also benefit from a forward reference to the section 5 on the\n> DOC signining? This would avoid Cornelius's case where he felt that section\n> 5 no longer applied.\n\nYeah I agree. My patch was not the best shot by far.\n"},{"id":"310312","messageId":"baff65ba-1e98-d5a7-5b5a-a50a7fc723ee@tngtech.com","threadId":"44947","inReplyTo":"CAGZ79kaRdtKD7DNJRWXsyg07GbTM4OsKUmHHcFczEMJA1YK2KA@mail.gmail.com","subject":"Re: SubmittingPatches: drop temporal reference for PGP signing","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-01-26T13:30:14Z","receivedAt":"2017-01-26T13:30:26Z","isPatch":false,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"\n> \n> Yeah I agree. My patch was not the best shot by far.\n> \n\nHow about something along these lines? Does the forward reference\nbreak the main line of thought too severly?\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 08352de..c2b0cbe 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -216,12 +216,12 @@ that it will be postponed.\n Exception: If your mailer is mangling patches then someone may ask\n you to re-send them using MIME, that is OK.\n \n-Do not PGP sign your patch, at least for now. Most likely, your\n-maintainer or other people on the list would not have your PGP\n-key and would not bother obtaining it anyway. Your patch is not\n-judged by who you are; a good patch from an unknown origin has a\n-far better chance of being accepted than a patch from a known,\n-respected origin that is done poorly or does incorrect things.\n+Do not PGP sign your patch, but do sign-off your work as explained in (5).\n+Most likely, your maintainer or other people on the list would not have your\n+PGP key and would not bother obtaining it anyway. Your patch is not judged by\n+who you are; a good patch from an unknown origin has a far better chance of\n+being accepted than a patch from a known, respected origin that is done poorly\n+or does incorrect things.\n \n If you really really really really want to do a PGP signed\n patch, format it as \"multipart/signed\", not a text/plain message\n@@ -246,7 +246,7 @@ patch.\n *2* The mailing list: git@vger.kernel.org\n \n \n-(5) Sign your work\n+(5) Certify your work by signing off\n \n To improve tracking of who did what, we've borrowed the\n \"sign-off\" procedure from the Linux kernel project on patches\n"},{"id":"310334","messageId":"CAGZ79kYChm3Y4T=Jk0-6cA3gEDpFDCHgXsP60pQ0afBDePWRXA@mail.gmail.com","threadId":"44947","inReplyTo":"baff65ba-1e98-d5a7-5b5a-a50a7fc723ee@tngtech.com","subject":"Re: SubmittingPatches: drop temporal reference for PGP signing","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-26T17:57:21Z","receivedAt":"2017-01-26T17:57:26Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jan 26, 2017 at 5:30 AM, Cornelius Weig\n wrote:\n>\n>>\n>> Yeah I agree. My patch was not the best shot by far.\n>>\n>\n> How about something along these lines? Does the forward reference\n> break the main line of thought too severly?\n>\n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index 08352de..c2b0cbe 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -216,12 +216,12 @@ that it will be postponed.\n> Exception: If your mailer is mangling patches then someone may ask\n> you to re-send them using MIME, that is OK.\n>\n> -Do not PGP sign your patch, at least for now. Most likely, your\n> -maintainer or other people on the list would not have your PGP\n> -key and would not bother obtaining it anyway. Your patch is not\n> -judged by who you are; a good patch from an unknown origin has a\n> -far better chance of being accepted than a patch from a known,\n> -respected origin that is done poorly or does incorrect things.\n> +Do not PGP sign your patch, but do sign-off your work as explained in (5).\n> +Most likely, your maintainer or other people on the list would not have your\n> +PGP key and would not bother obtaining it anyway. Your patch is not judged by\n> +who you are; a good patch from an unknown origin has a far better chance of\n> +being accepted than a patch from a known, respected origin that is done poorly\n> +or does incorrect things.\n>\n> If you really really really really want to do a PGP signed\n> patch, format it as \"multipart/signed\", not a text/plain message\n> @@ -246,7 +246,7 @@ patch.\n> *2* The mailing list: git@vger.kernel.org\n>\n>\n> -(5) Sign your work\n> +(5) Certify your work by signing off\n>\n> To improve tracking of who did what, we've borrowed the\n> \"sign-off\" procedure from the Linux kernel project on patches\n\nI like it.\n\nThanks,\nStefan\n"},{"id":"310338","messageId":"xmqqpoj965yf.fsf@gitster.mtv.corp.google.com","threadId":"44947","inReplyTo":"baff65ba-1e98-d5a7-5b5a-a50a7fc723ee@tngtech.com","subject":"Re: SubmittingPatches: drop temporal reference for PGP signing","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-26T18:18:00Z","receivedAt":"2017-01-26T18:18:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Cornelius Weig writes:\n\n> How about something along these lines? Does the forward reference\n> break the main line of thought too severly?\n\nI find it a bit distracting for those who know PGP signing has\nnothing to do with signing off your patch, but I think that is OK\nbecause they are not the primary target audience of this part of the\ndocument.\n\nI however am more worried that it may be misleading to mention these\ntwo in the same sentence. Those who skim these paragraphs without\nknowing the difference between the two may get a false impression\nthat these two may somehow be related because they are mentioned in\nthe same sentence.\n\nThe retitling of section (5) you did, without any other change,\nmight be sufficient. It may also help to be even more explicit in\nthe updated title, i.e. s/by signing off/by adding Signed-off-by:/\n\nThanks.\n\n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index 08352de..c2b0cbe 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -216,12 +216,12 @@ that it will be postponed.\n> Exception: If your mailer is mangling patches then someone may ask\n> you to re-send them using MIME, that is OK.\n> \n> -Do not PGP sign your patch, at least for now. Most likely, your\n> -maintainer or other people on the list would not have your PGP\n> -key and would not bother obtaining it anyway. Your patch is not\n> -judged by who you are; a good patch from an unknown origin has a\n> -far better chance of being accepted than a patch from a known,\n> -respected origin that is done poorly or does incorrect things.\n> +Do not PGP sign your patch, but do sign-off your work as explained in (5).\n> +Most likely, your maintainer or other people on the list would not have your\n> +PGP key and would not bother obtaining it anyway. Your patch is not judged by\n> +who you are; a good patch from an unknown origin has a far better chance of\n> +being accepted than a patch from a known, respected origin that is done poorly\n> +or does incorrect things.\n> \n> If you really really really really want to do a PGP signed\n> patch, format it as \"multipart/signed\", not a text/plain message\n> @@ -246,7 +246,7 @@ patch.\n> *2* The mailing list: git@vger.kernel.org\n> \n> \n> -(5) Sign your work\n> +(5) Certify your work by signing off\n> \n> To improve tracking of who did what, we've borrowed the\n> \"sign-off\" procedure from the Linux kernel project on patches\n"},{"id":"310358","messageId":"4B89512D54614F09817EA9901A8B625D@PhilipOakley","threadId":"44947","inReplyTo":"xmqqpoj965yf.fsf@gitster.mtv.corp.google.com","subject":"Re: SubmittingPatches: drop temporal reference for PGP signing","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-01-26T20:59:19Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \n> Cornelius Weig writes:\n>\n>> How about something along these lines? Does the forward reference\n>> break the main line of thought too severly?\n>\n> I find it a bit distracting for those who know PGP signing has\n> nothing to do with signing off your patch, but I think that is OK\n> because they are not the primary target audience of this part of the\n> document.\n\nAgreed. I this case the target audience was those weren't aware of that.\n>\n> I however am more worried that it may be misleading to mention these\n> two in the same sentence. Those who skim these paragraphs without\n> knowing the difference between the two may get a false impression\n> that these two may somehow be related because they are mentioned in\n> the same sentence.\n>\n> The retitling of section (5) you did, without any other change,\n> might be sufficient. It may also help to be even more explicit in\n> the updated title, i.e. s/by signing off/by adding Signed-off-by:/\n\nMaybe even s/by signing off/by adding your Signed-off-by:/ to be sure that \nthe reader knows that it is _their certification_ that is being sought. Even \nif it does double up on the 'your'.\n\n>\n> Thanks.\n>\n>> diff --git a/Documentation/SubmittingPatches \n>> b/Documentation/SubmittingPatches\n>> index 08352de..c2b0cbe 100644\n>> --- a/Documentation/SubmittingPatches\n>> +++ b/Documentation/SubmittingPatches\n>> @@ -216,12 +216,12 @@ that it will be postponed.\n>> Exception: If your mailer is mangling patches then someone may ask\n>> you to re-send them using MIME, that is OK.\n>>\n>> -Do not PGP sign your patch, at least for now. Most likely, your\n>> -maintainer or other people on the list would not have your PGP\n>> -key and would not bother obtaining it anyway. Your patch is not\n>> -judged by who you are; a good patch from an unknown origin has a\n>> -far better chance of being accepted than a patch from a known,\n>> -respected origin that is done poorly or does incorrect things.\n>> +Do not PGP sign your patch, but do sign-off your work as explained in \n>> (5).\n>> +Most likely, your maintainer or other people on the list would not have \n>> your\n>> +PGP key and would not bother obtaining it anyway. Your patch is not \n>> judged by\n>> +who you are; a good patch from an unknown origin has a far better chance \n>> of\n>> +being accepted than a patch from a known, respected origin that is done \n>> poorly\n>> +or does incorrect things.\n>>\n>> If you really really really really want to do a PGP signed\n>> patch, format it as \"multipart/signed\", not a text/plain message\n>> @@ -246,7 +246,7 @@ patch.\n>> *2* The mailing list: git@vger.kernel.org\n>>\n>>\n>> -(5) Sign your work\n>> +(5) Certify your work by signing off\n>>\n>> To improve tracking of who did what, we've borrowed the\n>> \"sign-off\" procedure from the Linux kernel project on patches\n> \n\n"},{"id":"310401","messageId":"60e9abdf-cc37-33d8-e7eb-8a3370ffe1cc@tngtech.com","threadId":"44947","inReplyTo":"4B89512D54614F09817EA9901A8B625D@PhilipOakley","subject":"Re: SubmittingPatches: drop temporal reference for PGP signing","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-01-27T10:49:26Z","receivedAt":"2017-01-27T10:49:36Z","isPatch":false,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"\n\nOn 01/26/2017 09:58 PM, Philip Oakley wrote:\n> From: \"Junio C Hamano\" \n>> Cornelius Weig writes:\n>>\n>>> How about something along these lines? Does the forward reference\n>>> break the main line of thought too severly?\n>>\n>> I find it a bit distracting for those who know PGP signing has\n>> nothing to do with signing off your patch, but I think that is OK\n>> because they are not the primary target audience of this part of the\n>> document.\n> \n> Agreed. I this case the target audience was those weren't aware of that.\n\nYes, maybe the forward reference does give a wrong hint about a\nconnection between sign-off and pgp-signing. However, I would still vote\nfor the following change suggested by sbeller@google.com:\n\n-Do not PGP sign your patch, -at least for now-. Most likely, your (...)\n+Do not PGP sign your patch. Most likely, your maintainer or other (...)\n\n\n> \n> Maybe even s/by signing off/by adding your Signed-off-by:/ to be sure\n> that the reader knows that it is _their certification_ that is being\n> sought. Even if it does double up on the 'your'.\n> \n\nI don't think doubling on the 'your' will make the heading clearer. The\nmain intention of this change is to avoid mixups with pgp-signing and\nthat would IMHO not improve by that.\nBesides, I find the colon in the heading a bit awkward. Is the following\nversion as expressive as with the colon?\n\n-(5) Sign your work\n+(5) Certify your work by adding Signed-off-by\n"},{"id":"310418","messageId":"xmqq60l01jr9.fsf@gitster.mtv.corp.google.com","threadId":"44947","inReplyTo":"60e9abdf-cc37-33d8-e7eb-8a3370ffe1cc@tngtech.com","subject":"Re: SubmittingPatches: drop temporal reference for PGP signing","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-27T17:43:22Z","receivedAt":"2017-01-27T17:45:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Cornelius Weig writes:\n\n> -Do not PGP sign your patch, -at least for now-. Most likely, your (...)\n> +Do not PGP sign your patch. Most likely, your maintainer or other (...)\n\nIt has been quite a while since we wrote that \"at least for now\", so\nit probably makes sense to drop it.\n\n>> Maybe even s/by signing off/by adding your Signed-off-by:/ to be sure\n>> that the reader knows that it is _their certification_ that is being\n>> sought. Even if it does double up on the 'your'.\n>\n> I don't think doubling on the 'your' will make the heading clearer. The\n> main intention of this change is to avoid mixups with pgp-signing and\n> that would IMHO not improve by that.\n> Besides, I find the colon in the heading a bit awkward. Is the following\n> version as expressive as with the colon?\n>\n> -(5) Sign your work\n> +(5) Certify your work by adding Signed-off-by\n\nI am leaning towards agreeing with Philip, and my gut feeling says\nthe presense of the colon, would help a lot. It would visually\nclick to readers what we are talking about.\n\nAt the same time, I think ending a section header with a colon would\nbe seen as \"awkward\". I would have written it more like this to\navoid it:\n\n ... by adding \"Signed-off-by: \" line\n\nI personally do not mind having \"your\" there, either, but I can see\nthat a section header wants to be kept shorter.\n"},{"id":"310441","messageId":"20170127211703.24910-2-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"20170127211703.24910-1-cornelius.weig@tngtech.com","subject":"[PATCH v2 7/7] completion: recognize more long-options","fromName":"","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-01-27T21:17:03Z","receivedAt":"2017-01-27T21:20:18Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"From: Cornelius Weig \n\nRecognize several new long-options for bash completion in the following\ncommands:\n\n - apply: --recount --directory=\n - archive: --output\n - branch: --column --no-column --sort= --points-at\n - clone: --no-single-branch --shallow-submodules\n - commit: --patch --short --date --allow-empty\n - describe: --first-parent\n - fetch, pull: --unshallow --update-shallow\n - fsck: --name-objects\n - grep: --break --heading --show-function --function-context\n --untracked --no-index\n - mergetool: --prompt --no-prompt\n - reset: --keep\n - revert: --strategy= --strategy-option=\n - rm: --force\n - shortlog: --email\n - tag: --merged --no-merged --create-reflog\n\nSigned-off-by: Cornelius Weig \nHelped-by: Johannes Sixt \n---\n contrib/completion/git-completion.bash | 31 +++++++++++++++++++++----------\n 1 file changed, 21 insertions(+), 10 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 0e09519..933bb6e 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -936,6 +936,7 @@ _git_apply ()\n \t\t\t--apply --no-add --exclude=\n \t\t\t--ignore-whitespace --ignore-space-change\n \t\t\t--whitespace= --inaccurate-eof --verbose\n+\t\t\t--recount --directory=\n \t\t\t\"\n \t\treturn\n \tesac\n@@ -974,7 +975,7 @@ _git_archive ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--format= --list --verbose\n-\t\t\t--prefix= --remote= --exec=\n+\t\t\t--prefix= --remote= --exec= --output\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -1029,6 +1030,7 @@ _git_branch ()\n \t\t\t--track --no-track --contains --merged --no-merged\n \t\t\t--set-upstream-to= --edit-description --list\n \t\t\t--unset-upstream --delete --move --remotes\n+\t\t\t--column --no-column --sort= --points-at\n \t\t\t\"\n \t\t;;\n \t*)\n@@ -1142,6 +1144,8 @@ _git_clone ()\n \t\t\t--single-branch\n \t\t\t--branch\n \t\t\t--recurse-submodules\n+\t\t\t--no-single-branch\n+\t\t\t--shallow-submodules\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -1183,6 +1187,7 @@ _git_commit ()\n \t\t\t--reset-author --file= --message= --template=\n \t\t\t--cleanup= --untracked-files --untracked-files=\n \t\t\t--verbose --quiet --fixup= --squash=\n+\t\t\t--patch --short --date --allow-empty\n \t\t\t\"\n \t\treturn\n \tesac\n@@ -1201,7 +1206,7 @@ _git_describe ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--all --tags --contains --abbrev= --candidates=\n-\t\t\t--exact-match --debug --long --match --always\n+\t\t\t--exact-match --debug --long --match --always --first-parent\n \t\t\t\"\n \t\treturn\n \tesac\n@@ -1284,6 +1289,7 @@ __git_fetch_recurse_submodules=\"yes on-demand no\"\n __git_fetch_options=\"\n \t--quiet --verbose --append --upload-pack --force --keep --depth=\n \t--tags --no-tags --all --prune --dry-run --recurse-submodules=\n+\t--unshallow --update-shallow\n \"\n \n _git_fetch ()\n@@ -1333,7 +1339,7 @@ _git_fsck ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--tags --root --unreachable --cache --no-reflogs --full\n-\t\t\t--strict --verbose --lost-found\n+\t\t\t--strict --verbose --lost-found --name-objects\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -1377,6 +1383,8 @@ _git_grep ()\n \t\t\t--max-depth\n \t\t\t--count\n \t\t\t--and --or --not --all-match\n+\t\t\t--break --heading --show-function --function-context\n+\t\t\t--untracked --no-index\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -1576,7 +1584,7 @@ _git_mergetool ()\n \t\treturn\n \t\t;;\n \t--*)\n-\t\t__gitcomp \"--tool=\"\n+\t\t__gitcomp \"--tool= --prompt --no-prompt\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2456,7 +2464,7 @@ _git_reset ()\n \n \tcase \"$cur\" in\n \t--*)\n-\t\t__gitcomp \"--merge --mixed --hard --soft --patch\"\n+\t\t__gitcomp \"--merge --mixed --hard --soft --patch --keep\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2472,7 +2480,10 @@ _git_revert ()\n \tfi\n \tcase \"$cur\" in\n \t--*)\n-\t\t__gitcomp \"--edit --mainline --no-edit --no-commit --signoff\"\n+\t\t__gitcomp \"\n+\t\t\t--edit --mainline --no-edit --no-commit --signoff\n+\t\t\t--strategy= --strategy-option=\n+\t\t\t\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2483,7 +2494,7 @@ _git_rm ()\n {\n \tcase \"$cur\" in\n \t--*)\n-\t\t__gitcomp \"--cached --dry-run --ignore-unmatch --quiet\"\n+\t\t__gitcomp \"--cached --dry-run --ignore-unmatch --quiet --force\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2500,7 +2511,7 @@ _git_shortlog ()\n \t\t__gitcomp \"\n \t\t\t$__git_log_common_options\n \t\t\t$__git_log_shortlog_options\n-\t\t\t--numbered --summary\n+\t\t\t--numbered --summary --email\n \t\t\t\"\n \t\treturn\n \t\t;;\n@@ -2778,8 +2789,8 @@ _git_tag ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--list --delete --verify --annotate --message --file\n-\t\t\t--sign --cleanup --local-user --force --column --sort\n-\t\t\t--contains --points-at\n+\t\t\t--sign --cleanup --local-user --force --column --sort=\n+\t\t\t--contains --points-at --merged --no-merged --create-reflog\n \t\t\t\"\n \t\t;;\n \tesac\n-- \n2.10.2\n\n"},{"id":"310442","messageId":"20170127211703.24910-1-cornelius.weig@tngtech.com","threadId":"44947","inReplyTo":"74ecd09c-55da-3858-5187-52c286a6bf62@kdbg.org","subject":"[PATCH v2 0/7] completion: recognize more long-options","fromName":"","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-01-27T21:17:02Z","receivedAt":"2017-01-27T21:20:46Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"From: Cornelius Weig \n\nThis revision addresses Johannes' concerns. Changes wrt v1:\n\n - fixed the commit message: two of the \"dangerous\" options erroneously ended\n up in the commit message. These options were already in the list of\n auto-completable options.\n - removed the possibly dangerous option '--unsafe-paths' from git-apply.\n - added my sign-off\n\nPatches 1-6 are not resent, because they have not changed (other than my added sign-off).\n\nAlso, I added further people to CC, because nobody actually has looked at the code yet.\n\n\nCornelius Weig (7):\n completion: recognize more long-options\n\n contrib/completion/git-completion.bash | 132 +++++++++++++++++++++++++++------\n 1 file changed, 110 insertions(+), 22 deletions(-)\n\n-- \n2.10.2\n\n"},{"id":"310627","messageId":"CAM0VKj=Ein4yrKG2aZnN7JU80ctZBQromcR6BEu-TyMLenLFCg@mail.gmail.com","threadId":"44947","inReplyTo":"20170127211703.24910-2-cornelius.weig@tngtech.com","subject":"Re: [PATCH v2 7/7] completion: recognize more long-options","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-01-31T22:17:50Z","receivedAt":"2017-01-31T22:19:04Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Jan 27, 2017 at 10:17 PM, wrote:\n> From: Cornelius Weig \n>\n> Recognize several new long-options for bash completion in the following\n> commands:\n\nAdding more long options that git commands learn along the way is\nalways an improvement. However, seeing \"_several_ new long options\"\n(or \"some long options\" in one of the other patches in the series)\nmakes the reader wonder: are these the only new long options missing\nor are there more? If there are more, why only these are added? If\nthere aren't any more missing long options left, then please say so,\ne.g. \"Add all missing long options, except the potentially\ndesctructive ones, for the following commands: ....\"\n\n\n> - apply: --recount --directory=\n> - archive: --output\n> - branch: --column --no-column --sort= --points-at\n> - clone: --no-single-branch --shallow-submodules\n> - commit: --patch --short --date --allow-empty\n> - describe: --first-parent\n> - fetch, pull: --unshallow --update-shallow\n> - fsck: --name-objects\n> - grep: --break --heading --show-function --function-context\n> --untracked --no-index\n> - mergetool: --prompt --no-prompt\n> - reset: --keep\n> - revert: --strategy= --strategy-option=\n> - rm: --force\n\n'--force' is a potentially destructive option, too.\n\n> - shortlog: --email\n> - tag: --merged --no-merged --create-reflog\n>\n> Signed-off-by: Cornelius Weig \n> Helped-by: Johannes Sixt \n> ---\n> contrib/completion/git-completion.bash | 31 +++++++++++++++++++++----------\n> 1 file changed, 21 insertions(+), 10 deletions(-)\n>\n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index 0e09519..933bb6e 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -936,6 +936,7 @@ _git_apply ()\n> --apply --no-add --exclude=\n> --ignore-whitespace --ignore-space-change\n> --whitespace= --inaccurate-eof --verbose\n> + --recount --directory=\n> \"\n> return\n> esac\n> @@ -974,7 +975,7 @@ _git_archive ()\n> --*)\n> __gitcomp \"\n> --format= --list --verbose\n> - --prefix= --remote= --exec=\n> + --prefix= --remote= --exec= --output\n> \"\n> return\n> ;;\n> @@ -1029,6 +1030,7 @@ _git_branch ()\n> --track --no-track --contains --merged --no-merged\n> --set-upstream-to= --edit-description --list\n> --unset-upstream --delete --move --remotes\n> + --column --no-column --sort= --points-at\n> \"\n> ;;\n> *)\n> @@ -1142,6 +1144,8 @@ _git_clone ()\n> --single-branch\n> --branch\n> --recurse-submodules\n> + --no-single-branch\n> + --shallow-submodules\n> \"\n> return\n> ;;\n> @@ -1183,6 +1187,7 @@ _git_commit ()\n> --reset-author --file= --message= --template=\n> --cleanup= --untracked-files --untracked-files=\n> --verbose --quiet --fixup= --squash=\n> + --patch --short --date --allow-empty\n> \"\n> return\n> esac\n> @@ -1201,7 +1206,7 @@ _git_describe ()\n> --*)\n> __gitcomp \"\n> --all --tags --contains --abbrev= --candidates=\n> - --exact-match --debug --long --match --always\n> + --exact-match --debug --long --match --always --first-parent\n> \"\n> return\n> esac\n> @@ -1284,6 +1289,7 @@ __git_fetch_recurse_submodules=\"yes on-demand no\"\n> __git_fetch_options=\"\n> --quiet --verbose --append --upload-pack --force --keep --depth=\n> --tags --no-tags --all --prune --dry-run --recurse-submodules=\n> + --unshallow --update-shallow\n> \"\n>\n> _git_fetch ()\n> @@ -1333,7 +1339,7 @@ _git_fsck ()\n> --*)\n> __gitcomp \"\n> --tags --root --unreachable --cache --no-reflogs --full\n> - --strict --verbose --lost-found\n> + --strict --verbose --lost-found --name-objects\n> \"\n> return\n> ;;\n> @@ -1377,6 +1383,8 @@ _git_grep ()\n> --max-depth\n> --count\n> --and --or --not --all-match\n> + --break --heading --show-function --function-context\n> + --untracked --no-index\n> \"\n> return\n> ;;\n> @@ -1576,7 +1584,7 @@ _git_mergetool ()\n> return\n> ;;\n> --*)\n> - __gitcomp \"--tool=\"\n> + __gitcomp \"--tool= --prompt --no-prompt\"\n> return\n> ;;\n> esac\n> @@ -2456,7 +2464,7 @@ _git_reset ()\n>\n> case \"$cur\" in\n> --*)\n> - __gitcomp \"--merge --mixed --hard --soft --patch\"\n> + __gitcomp \"--merge --mixed --hard --soft --patch --keep\"\n> return\n> ;;\n> esac\n> @@ -2472,7 +2480,10 @@ _git_revert ()\n> fi\n> case \"$cur\" in\n> --*)\n> - __gitcomp \"--edit --mainline --no-edit --no-commit --signoff\"\n> + __gitcomp \"\n> + --edit --mainline --no-edit --no-commit --signoff\n> + --strategy= --strategy-option=\n> + \"\n> return\n> ;;\n> esac\n> @@ -2483,7 +2494,7 @@ _git_rm ()\n> {\n> case \"$cur\" in\n> --*)\n> - __gitcomp \"--cached --dry-run --ignore-unmatch --quiet\"\n> + __gitcomp \"--cached --dry-run --ignore-unmatch --quiet --force\"\n> return\n> ;;\n> esac\n> @@ -2500,7 +2511,7 @@ _git_shortlog ()\n> __gitcomp \"\n> $__git_log_common_options\n> $__git_log_shortlog_options\n> - --numbered --summary\n> + --numbered --summary --email\n> \"\n> return\n> ;;\n> @@ -2778,8 +2789,8 @@ _git_tag ()\n> --*)\n> __gitcomp \"\n> --list --delete --verify --annotate --message --file\n> - --sign --cleanup --local-user --force --column --sort\n> - --contains --points-at\n> + --sign --cleanup --local-user --force --column --sort=\n> + --contains --points-at --merged --no-merged --create-reflog\n> \"\n> ;;\n> esac\n> --\n> 2.10.2\n>\n"},{"id":"310630","messageId":"20170131224241.25138-1-szeder.dev@gmail.com","threadId":"44947","inReplyTo":"20170122225724.19360-1-cornelius.weig@tngtech.com","subject":"Re: [PATCH 3/7] completion: improve bash completion for git-add","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-01-31T22:42:41Z","receivedAt":"2017-01-31T22:43:48Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"> Add some long-options for git-add and improve path completion when the\n> --update flag is given.\n\nPlease tell us in the commit message _how_ this improves path\ncompletion.\n\n> ---\n> contrib/completion/git-completion.bash | 10 +++++++---\n> 1 file changed, 7 insertions(+), 3 deletions(-)\n> \n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index 8329f09..652c7e2 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -947,13 +947,17 @@ _git_add ()\n> \t--*)\n> \t\t__gitcomp \"\n> \t\t\t--interactive --refresh --patch --update --dry-run\n> -\t\t\t--ignore-errors --intent-to-add\n> +\t\t\t--ignore-errors --intent-to-add --force --edit --chmod=\n\nI almost started complaining that '--force' should be used with care,\nbut then realized that for 'git add' it only means adding ignored\nfiles. So in this particular case '--force' is not destructive and we\ncan offer it among other long options. Good.\n\n> \t\t\t\"\n> \t\treturn\n> \tesac\n> \n> -\t# XXX should we check for --update and --all options ?\n> -\t__git_complete_index_file \"--others --modified --directory --no-empty-directory\"\n> +\tlocal complete_opt=\"--others --modified --directory --no-empty-directory\"\n> +\tif test -n \"$(__git_find_on_cmdline \"-u --update\")\"\n> +\tthen\n> +\t\tcomplete_opt=\"--modified\"\n> +\tfi\n> +\t__git_complete_index_file \"$complete_opt\"\n> }\n> \n> _git_archive ()\n> -- \n> 2.10.2\n\n\n"},{"id":"310650","messageId":"2841d2de-32ad-eae8-6039-9251a40bb00e@tngtech.com","threadId":"44947","inReplyTo":"CAM0VKj=Ein4yrKG2aZnN7JU80ctZBQromcR6BEu-TyMLenLFCg@mail.gmail.com","subject":"Re: [PATCH v2 7/7] completion: recognize more long-options","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-02-01T16:49:45Z","receivedAt":"2017-02-01T16:49:56Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"Hi Gabor,\n\n thanks for taking a look at these commits.\n\nOn 01/31/2017 11:17 PM, SZEDER Gábor wrote:\n> On Fri, Jan 27, 2017 at 10:17 PM, wrote:\n>> From: Cornelius Weig \n>>\n>> Recognize several new long-options for bash completion in the following\n>> commands:\n> \n> Adding more long options that git commands learn along the way is\n> always an improvement. However, seeing \"_several_ new long options\"\n> (or \"some long options\" in one of the other patches in the series)\n> makes the reader wonder: are these the only new long options missing\n> or are there more? If there are more, why only these are added? If\n> there aren't any more missing long options left, then please say so,\n> e.g. \"Add all missing long options, except the potentially\n> desctructive ones, for the following commands: ....\"\n\nPersonally, I agree with you that\n> Adding more long options that git commands learn along the way is\n> always an improvement.\nHowever, people may start complaining that their terminal becomes too\ncluttered when doing a double-Tab. In my cover letter, I go to length\nabout this. My assumption was that all options that are mentioned in the\nintroduction of the command man-page should be important enough to have\nthem in the completion list. I'll change my commit message accordingly.\n\n>> - rm: --force\n> \n> '--force' is a potentially destructive option, too.\n\nThanks for spotting this.\n\nBtw, I haven't found that non-destructive options should not be eligible\nfor completion. To avoid confusion about this in the future, I suggest\nto also change the documentation:\n\nindex 933bb6e..96f1c7f 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -13,7 +13,7 @@\n # *) git email aliases for git-send-email\n # *) tree paths within 'ref:path/to/file' expressions\n # *) file paths within current working directory and index\n-# *) common --long-options\n+# *) common non-destructive --long-options\n #\n # To use these routines:\n #\n\n\nI take it you have also looked at the code itself? Then I would gladly\nmention you as reviewer in my sign-off.\n"},{"id":"310692","messageId":"20170202005724.24754-1-szeder.dev@gmail.com","threadId":"44947","inReplyTo":"20170122225724.19360-3-cornelius.weig@tngtech.com","subject":"Re: [PATCH 2/7] completion: add subcommand completion for rerere","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-02-02T00:57:24Z","receivedAt":"2017-02-02T00:58:44Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"> Managing recorded resolutions requires command-line usage of git-rerere.\n> Added subcommand completion for rerere and path completion for its\n> subcommand forget.\n> ---\n> contrib/completion/git-completion.bash | 11 +++++++++++\n> 1 file changed, 11 insertions(+)\n> \n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index c54a557..8329f09 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -2401,6 +2401,17 @@ _git_replace ()\n> \t__gitcomp_nl \"$(__git_refs)\"\n> }\n> \n> +_git_rerere ()\n> +{\n> +\tlocal subcommands=\"clear forget diff remaining status gc\"\n> +\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n> +\tif test -z \"$subcommand\"\n> +\tthen\n> +\t\t__gitcomp \"$subcommands\"\n> +\t\treturn\n> +\tfi\n> +}\n> +\n> _git_reset ()\n> {\n> \t__git_has_doubledash && return\n> -- \n> 2.10.2\n\nYou didn't add 'rerere' to the list of porcelain commands, i.e. it\nwon't be listed after 'git '. I'm not saying it should be\nlisted there, because I can't decide whether 'rerere' is considered\nporcelain or plumbing... Just wanted to make sure that this omission\nwas intentional.\n\n"},{"id":"310693","messageId":"20170202013759.25789-1-szeder.dev@gmail.com","threadId":"44947","inReplyTo":"20170122225724.19360-7-cornelius.weig@tngtech.com","subject":"Re: [PATCH 6/7] completion: teach remote subcommands option completion","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-02-02T01:37:59Z","receivedAt":"2017-02-02T01:39:04Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"\n> Git-remote needs to complete remote names, its subcommands, and options\n> thereof. In addition to the existing subcommand and remote name\n> completion, do also complete the options\n> \n> - add: --track --master --fetch --tags --no-tags --mirror=\n\nOh, '--track' and '--master' are not even in the manpage or in 'git\nremote -h', I could only find them after looking at the source code...\n\nGood eyes :)\n\n> - set-url: --push --add --delete\n> - get-url: --push --all\n> - prune: --dry-run\n> ---\n> contrib/completion/git-completion.bash | 36 +++++++++++++++++++++++++++-------\n> 1 file changed, 29 insertions(+), 7 deletions(-)\n> \n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index e76cbd7..0e09519 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -2384,24 +2384,46 @@ _git_config ()\n> \n> _git_remote ()\n> {\n> -\tlocal subcommands=\"add rename remove set-head set-branches set-url show prune update\"\n> +\tlocal subcommands=\"\n> +\t\tadd rename remove set-head set-branches\n> +\t\tget-url set-url show prune update\n> +\t\t\"\n> \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n> \tif [ -z \"$subcommand\" ]; then\n> -\t\t__gitcomp \"$subcommands\"\n> +\t\tcase \"$cur\" in\n> +\t\t--*)\n> +\t\t\t__gitcomp \"--verbose\"\n> +\t\t\t;;\n> +\t\t*)\n> +\t\t\t__gitcomp \"$subcommands\"\n> +\t\t\t;;\n> +\t\tesac\n> \t\treturn\n> \tfi\n> \n> -\tcase \"$subcommand\" in\n> -\trename|remove|set-url|show|prune)\n> -\t\t__gitcomp_nl \"$(__git_remotes)\"\n> +\tcase \"$subcommand,$cur\" in\n> +\tadd,--*)\n> +\t\t__gitcomp \"--track --master --fetch --tags --no-tags --mirror=\"\n> \t\t;;\n> -\tset-head|set-branches)\n> +\tadd,*)\n> +\t\t;;\n> +\tset-head,*|set-branches,*)\n\nThe 'set-head' subcommand has '--auto' and '--delete' options, and\n'set-branches' has '--add'.\n\n> \t\t__git_complete_remote_or_refspec\n> \t\t;;\n> -\tupdate)\n> +\tupdate,*)\n\nThe 'update' subcommand has a '--prune' option.\n\nOtherwise it all looks good.\n\n\n> \t\t__gitcomp \"$(__git_get_config_variables \"remotes\")\"\n> \t\t;;\n> +\tset-url,--*)\n> +\t\t__gitcomp \"--push --add --delete\"\n> +\t\t;;\n> +\tget-url,--*)\n> +\t\t__gitcomp \"--push --all\"\n> +\t\t;;\n> +\tprune,--*)\n> +\t\t__gitcomp \"--dry-run\"\n> +\t\t;;\n> \t*)\n> +\t\t__gitcomp_nl \"$(__git_remotes)\"\n> \t\t;;\n> \tesac\n> }\n> -- \n> 2.10.2\n\n\n"},{"id":"310694","messageId":"20170202014014.25878-1-szeder.dev@gmail.com","threadId":"44947","inReplyTo":"20170122225724.19360-5-cornelius.weig@tngtech.com","subject":"Re: [PATCH 4/7] completion: teach ls-remote to complete options","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-02-02T01:40:14Z","receivedAt":"2017-02-02T01:41:00Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"\n> ls-remote needs to complete remote names and its own options.\n\nAnd refnames, too.\n\n> In\n> addition to the existing remote name completions, do also complete\n> the options --heads, --tags, --refs, and --get-url.\n\nWhy only these four options and not the other four?\n\nThere are eight options in total here, so there is really no chance\nfor cluttered terminals, and all eight are mentioned in the synopsis.\n\n> ---\n> contrib/completion/git-completion.bash | 6 ++++++\n> 1 file changed, 6 insertions(+)\n> \n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index 652c7e2..36fe439 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -1449,6 +1449,12 @@ _git_ls_files ()\n> \n> _git_ls_remote ()\n> {\n> +\tcase \"$cur\" in\n> +\t--*)\n> +\t\t__gitcomp \"--heads --tags --refs --get-url\"\n> +\t\treturn\n> +\t\t;;\n> +\tesac\n> \t__gitcomp_nl \"$(__git_remotes)\"\n> }\n> \n> -- \n> 2.10.2\n\n\n"},{"id":"310695","messageId":"CAM0VKjkAnsT_LE4OZRkLPuiEZW88P7_OBbOw0XovHhLYfBhbwg@mail.gmail.com","threadId":"44947","inReplyTo":"2841d2de-32ad-eae8-6039-9251a40bb00e@tngtech.com","subject":"Re: [PATCH v2 7/7] completion: recognize more long-options","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-02-02T02:00:08Z","receivedAt":"2017-02-02T02:00:14Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Feb 1, 2017 at 5:49 PM, Cornelius Weig\n wrote:\n> Hi Gabor,\n>\n> thanks for taking a look at these commits.\n>\n> On 01/31/2017 11:17 PM, SZEDER Gábor wrote:\n>> On Fri, Jan 27, 2017 at 10:17 PM, wrote:\n>>> From: Cornelius Weig \n>>>\n>>> Recognize several new long-options for bash completion in the following\n>>> commands:\n>>\n>> Adding more long options that git commands learn along the way is\n>> always an improvement. However, seeing \"_several_ new long options\"\n>> (or \"some long options\" in one of the other patches in the series)\n>> makes the reader wonder: are these the only new long options missing\n>> or are there more? If there are more, why only these are added? If\n>> there aren't any more missing long options left, then please say so,\n>> e.g. \"Add all missing long options, except the potentially\n>> desctructive ones, for the following commands: ....\"\n>\n> Personally, I agree with you that\n>> Adding more long options that git commands learn along the way is\n>> always an improvement.\n> However, people may start complaining that their terminal becomes too\n> cluttered when doing a double-Tab. In my cover letter, I go to length\n> about this. My assumption was that all options that are mentioned in the\n> introduction of the command man-page should be important enough to have\n> them in the completion list.\n\nBut that doesn't mean that the ones not mentioned in the synopsis\nsection are not worth completing.\n\nThe list of options listed by the completion script for several of\nthese commands fits on a single line. The command with the most\noptions among these is 'git pull', and even its options don't fill\nmore than half of a 80x25 screen. I see no danger of people coming\ncomplaining.\n\n> I'll change my commit message accordingly.\n>\n>>> - rm: --force\n>>\n>> '--force' is a potentially destructive option, too.\n>\n> Thanks for spotting this.\n>\n> Btw, I haven't found that non-destructive options should not be eligible\n> for completion. To avoid confusion about this in the future, I suggest\n> to also change the documentation:\n>\n> index 933bb6e..96f1c7f 100644\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -13,7 +13,7 @@\n> # *) git email aliases for git-send-email\n> # *) tree paths within 'ref:path/to/file' expressions\n> # *) file paths within current working directory and index\n> -# *) common --long-options\n> +# *) common non-destructive --long-options\n\nI don't mind such a change, but I don't think that list was ever meant\nto be comprehensive or decisive. It is definitely not the former, as\nit's missing several things that the completion script does support.\nOTOH, it talks about .git/remotes, which has been considered legacy\nfor quite some years (though it's right, because the completion script\nstill supports it).\n\n> I take it you have also looked at the code itself? Then I would gladly\n> mention you as reviewer in my sign-off.\n\nYeah, most of the changes was rather straightforward, except the\ncompletion of 'git remote's subcommands' options, but that looks\ngood, too.\n\nGábor\n"},{"id":"310716","messageId":"303e3381-ad15-c991-afc2-3a55706142f3@tngtech.com","threadId":"44947","inReplyTo":"20170202005724.24754-1-szeder.dev@gmail.com","subject":"Re: [PATCH 2/7] completion: add subcommand completion for rerere","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-02-02T09:16:34Z","receivedAt":"2017-02-02T09:16:45Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"\n\nOn 02/02/2017 01:57 AM, SZEDER Gábor wrote:\n> You didn't add 'rerere' to the list of porcelain commands, i.e. it\n> won't be listed after 'git '. I'm not saying it should be\n> listed there, because I can't decide whether 'rerere' is considered\n> porcelain or plumbing... Just wanted to make sure that this omission\n> was intentional.\n\nYes this is intentional. There is a number of plumbing commands that\nhave command completion, but are not listed in 'git ' (e.g.\nls-tree, ls-files, ls-remote, ...). Given that rerere will not be\nfrequently invoked, I would not add it to the porcelain commands.\n"},{"id":"310723","messageId":"603697da-c8e9-5644-e0f0-7ee265c069d8@tngtech.com","threadId":"44947","inReplyTo":"20170202014014.25878-1-szeder.dev@gmail.com","subject":"Re: [PATCH 4/7] completion: teach ls-remote to complete options","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-02-02T09:40:53Z","receivedAt":"2017-02-02T09:41:08Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"\n\nOn 02/02/2017 02:40 AM, SZEDER Gábor wrote:\n> \n>> ls-remote needs to complete remote names and its own options.\n> \n> And refnames, too.\n\nYes, right. However, do you think it is reasonable to complete remote\nrefnames? I don't think so, because it would mean we would have to run\nls-remote during completion -- and waiting for ls-remote could be quite\nlengthy.\n\n>> In\n>> addition to the existing remote name completions, do also complete\n>> the options --heads, --tags, --refs, and --get-url.\n> \n> Why only these four options and not the other four?\n> \n> There are eight options in total here, so there is really no chance\n> for cluttered terminals, and all eight are mentioned in the synopsis.\n\nMy line of thought is the following:\n\n--quiet: does not print anything and is therefore only useful for\nscripting. Thus, there is no need to have it on the command line completion.\n\n--exit-code: has no visible effect and is only useful for scripting.\n\n--upload-pack: is really exotic. Nobody will ever use it without digging\ndeep in the manuals. Therefore, I think it's unnecessary to have the\noption completable.\n\n\n--symref: Should probably be added, thanks.\n\nHowever, if you don't find my reasoning for omitting the three options\nabove conclusive, I have no problem including them.\n"},{"id":"311175","messageId":"16f6cc98-1467-27cf-1beb-3160358add5c@tngtech.com","threadId":"44947","inReplyTo":"20170202013759.25789-1-szeder.dev@gmail.com","subject":"Re: [PATCH 6/7] completion: teach remote subcommands option completion","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-02-02T10:29:39Z","receivedAt":"2017-02-02T10:29:39Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"\n\nOn 02/02/2017 02:37 AM, SZEDER Gábor wrote:\n> The 'set-head' subcommand has '--auto' and '--delete' options, and\n> 'set-branches' has '--add'.\n\nOops. Thanks for spotting this..\n\n>> \t\t__git_complete_remote_or_refspec\n>> \t\t;;\n>> -\tupdate)\n>> +\tupdate,*)\n> \n> The 'update' subcommand has a '--prune' option.\n> \n\n..and that.\n"},{"id":"310727","messageId":"415570bf-7201-3b68-4c91-668741d50160@tngtech.com","threadId":"44947","inReplyTo":"CAM0VKjkAnsT_LE4OZRkLPuiEZW88P7_OBbOw0XovHhLYfBhbwg@mail.gmail.com","subject":"Re: [PATCH v2 7/7] completion: recognize more long-options","fromName":"Cornelius Weig","fromEmail":"cornelius.weig@tngtech.com","sentAt":"2017-02-02T10:40:00Z","receivedAt":"2017-02-02T10:40:12Z","isPatch":true,"sender":{"key":"cornelius.weig@tngtech.com","avatar":null},"body":"On 02/02/2017 03:00 AM, SZEDER Gábor wrote:\n>> Personally, I agree with you that\n>>> Adding more long options that git commands learn along the way is\n>>> always an improvement.\n>> However, people may start complaining that their terminal becomes too\n>> cluttered when doing a double-Tab. In my cover letter, I go to length\n>> about this. My assumption was that all options that are mentioned in the\n>> introduction of the command man-page should be important enough to have\n>> them in the completion list.\n> \n> But that doesn't mean that the ones not mentioned in the synopsis\n> section are not worth completing.\n\nAbsolutely. What I meant is that at least the options from the synopsis\nshould be contained in the set of completable options.\n\n>> Btw, I haven't found that non-destructive options should not be eligible\n>> for completion. To avoid confusion about this in the future, I suggest\n>> to also change the documentation:\n>>\n>> index 933bb6e..96f1c7f 100644\n>> --- a/contrib/completion/git-completion.bash\n>> +++ b/contrib/completion/git-completion.bash\n>> @@ -13,7 +13,7 @@\n>> # *) git email aliases for git-send-email\n>> # *) tree paths within 'ref:path/to/file' expressions\n>> # *) file paths within current working directory and index\n>> -# *) common --long-options\n>> +# *) common non-destructive --long-options\n> \n> I don't mind such a change, but I don't think that list was ever meant\n> to be comprehensive or decisive. It is definitely not the former, as\n> it's missing several things that the completion script does support.\n> OTOH, it talks about .git/remotes, which has been considered legacy\n> for quite some years (though it's right, because the completion script\n> still supports it).\n\nThen let's not do that change, because for some commands destructive\nlong-options have been in the list of completed options for quite a\nwhile. Given that, the above change of the documentation, might stir up\nmore confusion than it settles.\n"},{"id":"310733","messageId":"xmqqwpd8leda.fsf@gitster.mtv.corp.google.com","threadId":"44947","inReplyTo":"603697da-c8e9-5644-e0f0-7ee265c069d8@tngtech.com","subject":"Re: [PATCH 4/7] completion: teach ls-remote to complete options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-02T16:57:37Z","receivedAt":"2017-02-02T17:05:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Cornelius Weig writes:\n\n> On 02/02/2017 02:40 AM, SZEDER Gábor wrote:\n>> \n>>> ls-remote needs to complete remote names and its own options.\n>> \n>> And refnames, too.\n>\n> Yes, right. However, do you think it is reasonable to complete remote\n> refnames? I don't think so, because it would mean we would have to run\n> ls-remote during completion -- and waiting for ls-remote could be quite\n> lengthy.\n\n... and by the time the completion script knew what they are, we\nhave all information necessary without actually having the user run\nthe command ;-) That does sound backwards.\n\nI am however not sure what Szeder really meant by \"refnames\". For\nexample, you may want to see that this\n\n\t$ git ls-remote origin mast\n\npeek into refs/remotes/origin/* and find those matching, i.e. most\nlikely \"master\", and that can be done without talking to the remote\nside. It won't catch the case where the remote end added a new\nbranch that also match, e.g. \"mastiff\", and it will actively harm\nthe users by giving the impression that Git (collectively, even\nthough from technical point of view, what the completion script does\nis not part of Git) told them that there is no such new branch they\nneed to worry about.\n\nSo probably even with the \"peek local\" optimization, I have a feeling\nthat completion of refnames may not be such a good idea.\n"}]}