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
