On Fri, Jun 03, 2016 at 09:34:00AM -0700, Junio C Hamano wrote:
> Thomas Braun <thomas.braun@xxxxxxxxxxxxxxxxxxx> writes:
>
> >>> + if [ -n "$(__git_find_on_cmdline "--ignored")" ]; then
> >>
> >> Same question as the "--untracked-files=no vs -uno" applies here.
> >
> > Is there a short version of --ignored? I could not find one in the help,
> > and from a look into cmd_status in commit.c I would say there is none.
>
> I was primarily wondering about the effect of parse-options have.
> It lets you truncate a long option to its unique prefix (e.g.
> "--untracked-files=all" can be spelled as "--unt=all"). It seems
> that "--ignored" must be spelled in full, which means the use of
> find-on-cmdline we see above is OK, but the reason why it is so is a
> bit subtle. It may deserve a comment there, perhaps.
I don't think we handle arguments to unique-prefix options throughout
the completion. There's lots of:
case "${words[c]}" in
--foo) ...
--bar) ...
--etc) ...
I suspect trying to support them everywhere would be a moderate pain,
and I doubt it is all that useful. We already know the person is using
tab-completion, so the natural thing to do after typing "--unt" is to
hit "<Tab>" rather than "=". That gives you the same effect, with the
added feedback that you're using a recognized action.
I know not everybody will the "natural thing" I claim, and if it were
easy to support everywhere, I don't mind doing it. But I suspect
(without thinking very hard on it) that it would make those case
statements a bit harder to read and maintain.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html