threads / discuss / 36696

Bash completion: merge --abort

Subject: Bash completion: merge --abort

## tl;dr

4 messages between May 19, 2014 and May 22, 2014.

replies: 3people: 3as markdown or json

Haralan Dobrev· May 19, 2014, 08:36 UTC · lore
Hi all!

The Git Bash completion script does not complete the `--abort` option for the `merge ` command.

It correctly completes the other flags. It correctly completes the `--abort` flag for `rebase` and others.

`git merge --abort` is considered another form of the merge command instead of a simple option. This could be the cause of the completion to be missed from the script.

Cheers!
John Keeping· May 22, 2014, 13:58 UTC · re: Haralan Dobrev · lore

[PATCH 1/2] completion: add a note that merge options are shared

This should avoid future confusion after a subsequent patch has added some options to __git_merge_options and some directly in _git_merge().

Signed-off-by: John Keeping <john@keeping.me.uk>
---
 contrib/completion/git-completion.bash | 1 +
 1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2c59a76..ff97c20 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1472,6 +1472,7 @@ _git_log ()
 	__git_complete_revlist
 }
 
+# Common merge options shared by git-merge(1) and git-pull(1).
 __git_merge_options="
 	--no-commit --no-stat --log --no-log --squash --strategy
 	--commit --stat --no-squash --ff --no-ff --ff-only --edit --no-edit
-- 
2.0.0.rc2.4.g1dc51c6
John Keeping· May 22, 2014, 13:58 UTC · re: John Keeping · lore

[PATCH 2/2] completion: add missing options for git-merge

The options added to __git_merge_options are those that git-pull also understands, since that variable is used by both commands. Those added directly in _git_merge() are specific to git-merge and are not supported by git-pull.

Reported-by: Haralan Dobrev <hkdobrev@gmail.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
---
 contrib/completion/git-completion.bash | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index ff97c20..019026e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1476,6 +1476,8 @@ _git_log ()
 __git_merge_options="
 	--no-commit --no-stat --log --no-log --squash --strategy
 	--commit --stat --no-squash --ff --no-ff --ff-only --edit --no-edit
+	--verify-signatures --no-verify-signatures --gpg-sign
+	--quiet --verbose --progress --no-progress
 "
 
 _git_merge ()
@@ -1484,7 +1486,8 @@ _git_merge ()
 
 	case "$cur" in
 	--*)
-		__gitcomp "$__git_merge_options"
+		__gitcomp "$__git_merge_options
+			--rerere-autoupdate --no-rerere-autoupdate --abort"
 		return
 	esac
 	__gitcomp_nl "$(__git_refs)"
-- 
2.0.0.rc2.4.g1dc51c6
Junio C Hamano· May 22, 2014, 23:59 UTC · re: John Keeping · lore

Re: [PATCH 2/2] completion: add missing options for git-merge

John Keeping <john@keeping.me.uk> writes:
> The options added to __git_merge_options are those that git-pull also
> understands, since that variable is used by both commands.  Those added
> directly in _git_merge() are specific to git-merge and are not
> supported by git-pull.
Interesting.

Technically, "are not passed through" would be more accurate than "are not supported", as there may be a very good reason not to call "git merge --frotz" from "git pull --frotz=nitfol". In such a case, "git pull" would _support_ the "--frotz" option, but in a different way and possibly with semantics different from "git merge --frotz" (i.e. option with value vs boolean), and completion of the "--frotz=<value>" option may need to be supported for "git pull" separately without using $__git_merge_options.

The patch makes us think if "--[no-]rerere-autoupdate" should be a pass-thru option. You are unlikely to have seen the same conflict that will arise from a pull from another person for autoupdate to matter, but on the other hand, if you do have seen one and resolved it already, you may want the autoupdate to kick in, so accepting and passing it through may not be an unreasonable thing to do.

As long as we declare that "git pull --abort" does not make any sense (which I think is a sane declaration), the distinction you made in [PATCH 1/2] will always be with us, whether we make "--rerere-autoupdate" pass-thru or not, so in that sense, both patches make sense to me.

Thanks.
Show 30 quoted lines
>
> Reported-by: Haralan Dobrev <hkdobrev@gmail.com>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
>  contrib/completion/git-completion.bash | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index ff97c20..019026e 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1476,6 +1476,8 @@ _git_log ()
>  __git_merge_options="
>  	--no-commit --no-stat --log --no-log --squash --strategy
>  	--commit --stat --no-squash --ff --no-ff --ff-only --edit --no-edit
> +	--verify-signatures --no-verify-signatures --gpg-sign
> +	--quiet --verbose --progress --no-progress
>  "
>  
>  _git_merge ()
> @@ -1484,7 +1486,8 @@ _git_merge ()
>  
>  	case "$cur" in
>  	--*)
> -		__gitcomp "$__git_merge_options"
> +		__gitcomp "$__git_merge_options
> +			--rerere-autoupdate --no-rerere-autoupdate --abort"
>  		return
>  	esac
>  	__gitcomp_nl "$(__git_refs)"

← back to recent threads