On Mon, Sep 1, 2008 at 23:44, Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> wrote: > On Mon, Sep 1, 2008 at 23:28, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> "Bert Wesarg" <bert.wesarg@xxxxxxxxxxxxxx> writes: >> >>> On Mon, Sep 1, 2008 at 21:10, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: >>> ... >>>> You can still get ambiguous names. Avoiding them requires going >>>> through all refs and building their short forms, then using the >>>> full ref name for any ref which had more than one name shorten to >>>> the same string. Ugly, but implementable, and probably something >>>> that should be considered. >>> >>> What about: try the list backwards until the first match, than try the >>> matched part (this what %.*s matched) with the forward list, if both >>> give the same pattern, its not disambiguous. If not try the next >>> pattern backwards. >> >> How does it catch the case where you have both 'xyzzy' branch and 'xyzzy' >> tag, which is the point of disambiguation issue Shawn raised? > Right. I was wrong: given these two refs: refs/heads/xyzzy refs/tags/xyzzy first try to shorten "refs/heads/xyzzy": first (from the end) matched pattern is "refs/heads/%.*s" with "xyzzy" as result but resolved ref for "xyzzy" is "refs/tags/xyzzy" => continue next matched pattern is "%.*s" with "refs/heads/xyzzy" as result end result is therefore: "refs/heads/xyzzy" second try to shorten "refs/tags/xyzzy": first (from the end) matched pattern is "refs/tags/%.*s" with "xyzzy" as result resolved ref for "xyzzy" is "refs/tags/xyzzy" => end end result is therefore: "xyzzy" the output would be: refs/heads/xyzzy xyzzy The question is now, if this is usable for bash completion? Current bash completion would handle this case wrong, because you get two xyzzy. 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
