On Tue, Sep 9, 2008 at 10:05, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "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. A really nice idea. Await PATCH v5. I had to change my plans for today, unfortunately. Bert > -- 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
