Re: [PATCH v2] for-each-ref: `:short` format for `refname`

From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Sep 3, 2008, 08:33 UTC
Message-ID: <36ca99e90809030133r43fc5a3agad1aa38339a758a3@mail.gmail.com>
In-Reply-To: <7v63pei1pz.fsf@gitster.siamese.dyndns.org>

On Wed, Sep 3, 2008 at 01:10, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

> Bert Wesarg <bert.wesarg@googlemail.com> 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.

Show 8 quoted lines

>
> 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