On Mon, Sep 1, 2008 at 21:10, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:> Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> wrote:>> IMHO the goal of this new format for refname should be, that it can be>> used as an ref on the command line. This isn't given with my current>> :short proposal (which I call :strip as of now), as Gábor showed. What>> we need is the reverse of what happened with refnames given on the>> command line to commands like checkout/merge/... The only thing that>> comes near to this is this from refs.c:>>>> const char *ref_rev_parse_rules[] = {>> "%.*s",>> "refs/%.*s",>> "refs/tags/%.*s",>> "refs/heads/%.*s",>> "refs/remotes/%.*s",>> "refs/remotes/%.*s/HEAD",>> NULL>> };>>>> Which doesn't look very useful, because every ref from for_each_ref>> would match rule one. So we probably need to try the reverse of this>> list.>> Yup. If you search the list backwards and extract the part of the> ref that matches %.*s you'll get a name that other tools can find,> and which is the shortest name possible.>> 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 thematched part (this what %.*s matched) with the forward list, if bothgive the same pattern, its not disambiguous. If not try the nextpattern backwards.
Its quadratic in the number of patterns, but this is maybe smallerthan scanning all refs (which may include a sort phase).
Bert> --> Shawn.>��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
