"Marco Costalba" <mcostalba@xxxxxxxxx> writes:
> On 11/18/06, Petr Baudis <pasky@xxxxxxx> 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).
-
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