From: Junio C Hamano <junkio@cox.net>
Date: Sat, 18 Nov 2006 19:04:20 GMT
Subject: Re: [WISH] Store also tag dereferences in packed-refs
Message-ID: <7vac2oefuz.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <e5bfff550611181047w6712774fkccc697d312b87c7e@mail.gmail.com>

"Marco Costalba" <mcostalba@gmail.com> writes:

> On 11/18/06, Petr Baudis <pasky@suse.cz> wrote:
>> On Sat, Nov 18, 2006 at 07:38:11PM CET, Junio C Hamano wrote:
>> >
>> > I think the question is why you would want to run peek-remote.
>> > Do you use the ^{} peeled-onion information and if so how and
>> > why?
>>..
> Yes. It is. From a list like
>
>> > > d9b0f913ce0508fcc83e642e0241f373428368e5        refs/tags/v1.4.3
>> > > e0b0830726286287744cc9e1a629a534bbe75452        refs/tags/v1.4.3^{}
>> > > 4314f5982d2aac08001a977fc0b1b611e858e025        refs/tags/v1.4.3-rc1
>> > > 1965efb1599f59b8e3380335d1fa395e2008a30b        refs/tags/v1.4.3-rc1^{}
>>
> qgit (but also gitk FWIK) extracts
>
> e0b0830726286287744cc9e1a629a534bbe75452
> 1965efb1599f59b8e3380335d1fa395e2008a30b
>
> Stores in a quick look-up container and then checks against loaded
> commits to, as Pasky says, attach the nice green markers to tags.

Two answers.

A quick one that is to the point to solve "your" problem.

	show-ref -d

Not a quick one but that may lead to solution of a similar issue
for wider audiences is...

I wonder how fast update-server-info is under the same condition
with your earlier timing.

I am not suggesting you to use update-server-info.  The reason I
am wondering about it are:

 (1) traditionally, "peek-remote ." has been the only way to get
     to that information, so you have every right to keep doing
     so;

 (2) however, even with presense of packed-refs, upload-pack
     that is invoked by peek-remote needs to consult unpacked
     refs first and then fall back to packed-refs, and only
     using the ^{} information "cached" in packed-refs file and
     computing ^{} itself when dealing with unpacked refs means
     more code, which we need to assess the pros-and-cons.

 (3) another inefficiency of using "peek-remote ." is that it
     spawns another process in the "remote" repo and talks with
     it.

So storing this information making upload-pack to reuse it when
it can might make things go faster for other applications but
first I wanted to know how much overhead is incurred in the
extra upload-pack process, and time update-server-info needs to
prepare the info in .git/info/refs would be a way to get a rough
estimate for that (you subtract that from "peek-remote ." time).