On Wed, Sep 3, 2008 at 01:10, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> writes:
>
>> Tries to shorten the refname to a non-ambiguous name.
>> I.e. the full and the short refname points to the same object.
>
> The definition of "ambiguity" here is wrong (see below).
>
>> + * by checking all rules in forward direction
>> + */
>
> I think this part of the code is wrong, in that it talks about what object
> the ref points at. That is not what ref ambiguity is about.
>
> Given a tag that points at a version 1.0.0 commit, this sequence will
> create:
>
> $ git tag foo v1.0.0^0
> $ git branch foo v1.0.0^0
>
> ambiguous branch and tag whose names are both 'foo', even though they
> point at the same thing. The right API to use would be resolve_ref(), I
> think.
I use resolve_ref():
int read_ref(const char *ref, unsigned char *sha1)
{
if (resolve_ref(ref, sha1, 1, NULL))
return 0;
return -1;
}
Ok, I think I get your point: it doesn't matter if the full and short
point to different objects, it's enough for ambiguity that the short
name resolves to more than one ref.
New patch in reply.
>
> Other than that, it is well done.
>
> Although I was initially a bit surprised by the size of the patch to
> implement something so (conceptually) simple, the code was easy and
> straightforward to follow.
>
> Thanks.
Your welcome.
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
