Bring completion for bisect up to date with current features.
This is RFC mainly because of an implementation issue in patch 2: I think
the mechanism of requiring COMPREPLY to be empty, possibly writing into it,
then checking it post-call is too fragile, but I'm not sure how people would
like to fix this. I'd prefer to just add an assert() of some sort to enforce
the empty-COMPREPLY precondition, rather than rewrite the guts of the former
_git_log() function to use some other intermediate return mechanism (this
would be overkill in this simple context IMO). But I'm not sure how to
do that in a completion context: for sure nothing that is done here should
ever have a chance of showing garbage on a user's screen, but of course for
assert() to be useful a dev would need to see it somehow. Suggestions welcome.
Other than that issue I think it's all reasonable and ready, though there
are a couple other decisions that I guess people might disagree with:
* good/old/new/bad terms are always completed (even if they're
invalild because --term-(good|bad) have been used). The idea here
is that if the user has become confused about their own terms it's
better to let git give them an error message than to have
normally-working completion not happen.
* 'view' is recognized as a subcommand, but not as a completion
candidate. This lets complete of git bisect v<TAB> keep working which
seems convenient and some poor person somewhere probably really wants :)
view is just an alias so loss of interface recall is minimal.
Britton Leo Kerin (6):
completion: complete new old actions, start opts
completion: git-log opts to bisect visualize
completion: move to maintain define-before-use
completion: custom git-bisect terms
completion: recognize but do not complete 'view'
completion: add comment
contrib/completion/git-completion.bash | 310 +++++++++++++++----------
1 file changed, 181 insertions(+), 129 deletions(-)
base-commit: e79552d19784ee7f4bbce278fe25f93fbda196fa
--
2.43.0
