contrib: Add --recursive flag for bash completion

This flag was missing from the list, and I use it quite often :)

Thanks for taking the time to contribute to Git! Please be advised that the Git community does not use github.com for their contributions. Instead, we use a mailing list ([email protected]) for code submissions, code reviews, and bug reports. Nevertheless, you can use GitGitGadget (
https://gitgitgadget.github.io/) to conveniently send your Pull Requests commits to our mailing list.

Please read the "guidelines for contributing" linked above!

James Shubin (1):
contrib: Add --recursive flag for bash completion

 contrib/completion/git-completion.bash | 1 +
 1 file changed, 1 insertion(+)

base-commit: d9f6f3b6195a0ca35642561e530798ad1469bd41
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-461%2Fpurpleidea%2Ffeat%2Fcompletion-recursive2-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-461/purpleidea/feat/completion-recursive2-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/461

gitgitgadget

From: James Shubin <[email protected]>

This flag was missing from the list, and I use it quite often :)

---
 contrib/completion/git-completion.bash | 1 +
 1 file changed, 1 insertion(+)

index 00fbe6c03d..79fe29ef03 100644
@@ -2843,6 +2843,7 @@ _git_svn ()
 			--log-window-size= --no-checkout --quiet
 			--repack-flags --use-log-author --localtime
 			--add-author-from
+			--recursive
 			--ignore-paths= --include-paths= $remote_opts
 			"
 		local init_opts="

gitgitgadget

The title must make it clear which git subcommand learned the "--recursive" (unless the patch adds it to everything, that is).

    Subject: [PATCH] completion: tab-complete "git svn --recursive"

By the way, it is pointless to send a cover letter for a single patch topic like this; you may want to tell GGG not to do so.

Makes sense.

Thanks. Will queue with title updated locally.

Hi Junio,

In this instance, I totally agree. But in this instance, it would also have made sense to at least scrub the PR description template before sending. Also, it would have made sense to listen to Emily who suggested to have another go at the commit message before sending.

Thanks,
Johannes