Hi,
Quoting Trygve Aaberge <trygv...@gmail.com>:
When using the exclude pattern, ^<rev>, the completion did not work.
This enables completion after ^ in the same way that completion after ..
is done.
Interesting, thinking back I can't recall I've ever needed multiple
exclude patterns on the command line, and a single exclude is well
served by the rev1..rev2 notion.
Of course that doesn't mean that nobody might need it, and since it's
easy to implement, I'm for it.
Signed-off-by: Trygve Aaberge <trygv...@gmail.com>
---
contrib/completion/git-completion.bash | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 8cfee95..3036dac 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -496,6 +496,10 @@ __git_complete_revlist_file ()
cur_="${cur_#*..}"
__gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
;;
+ ^*)
+ cur_="${cur_#^}"
+ __gitcomp_nl "$(__git_refs)" "^" "$cur_"
+ ;;
This is good, but considering the other cases I suggest making this
the very first case. That way we would not complete e.g. refs after
'^rev..<TAB>', which would lead to a "bad revision" error when the
command is executed, or tracked paths after '^rev:<TAB>', which I
think doesn't make sense, though doesn't lead to error.
*)
__gitcomp_nl "$(__git_refs)"
;;
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
