"Bert Wesarg" <bert.wesarg@xxxxxxxxxxxxxx> writes:
> Any opinions, whether we want the 'strict' mode? i.e.:
>
> for refs/heads/xyzzy and refs/tags/xyzzy:
>
> loose mode (current implementation):
>
> refs/heads/xyzzy => heads/xyzzy
> refs/tags/xyzzy => xyzzy
>
> there would be a ambiguous warning (if enabled) if you use xyzzy as a
> tag, but it resolves correctly to the tag.
>
> strict mode:
>
> refs/heads/xyzzy => heads/xyzzy
> refs/tags/xyzzy => tags/xyzzy
>
> will always produce a non-ambiguous short forms.
I have no strong opinions either way, but if we want to pick only one, I
suspect that the loose mode would be more appropriate for bash completion
purposes exactly because:
(1) the shorter form would match the users' expectations, and;
(2) if it triggers ambiguity warning to use that result that matches
users' expectations, it is a *good thing* --- it reminds the user
that s/he is playing with fire _if_ the user is of careful type who
enables the ambiguity warning.
Thinking about it from a different angle, it would make more sense to use
loose mode if the user does not have ambiguity warning configured, and use
strict mode if the warning is enabled. Then people who will get warnings
from ambiguity will not get an ambiguous completion, and people who won't
will get shorter but still unambiguous completion.
Which means, despite what I said earlier, now I have a mild preference to
tie the choice to core.wawrnambigousrefs configuration.
--
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
