Re: Change set based shallow clone

From: Junio C Hamano <junkio@cox.net>
Date: Sep 11, 2006, 06:35 UTC
Message-ID: <7vk64anc5x.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0609102002300.27779@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 29 quoted lines

> On Sun, 10 Sep 2006, Linus Torvalds wrote:
>> 
>> If we did the same pack-file approach that we do for objects, the problem 
>> ends up being that _updating_ things is really hard. What we could do (and 
>> might work) is that a "git repack" would create a "packed representation 
>> of the heads too".
>
> To clarify: I'm _not_ suggesting actually using the "pack-file" 
> representation itself for the references.
>
> I'm saying that we could have something like a
>
> 	.git/refs-packed
>
> file, which could be (for example) just a plain linear text-file, of the 
> form
>
> 	19ed368b17abfb9ad5c7467ea74fd8a045d96b43	refs/heads/html
> 	60a6bf5f53635005f4f68d8b8a33172309193623	refs/heads/maint
> 	...
>
> ie it would contain just a linear file with the "<hex></tab><refname>"
> format.  Then, the way to look up a reference would be:
>...
> NOTE! It's important that whatever sceme used gets locking right. The 
> above suggestion gets it right simply because it doesn't really _change_ 
> anything. Any new or modified ref ends up using the old code, and using a 
> ".lock" file and renaming it automatically does the same thing it ever 
> did.

This is all interesting and can be done by somebody interested in the really core part of the system.

I was just looking at Paul's "new" branch, and realized that there is something else that somebody _else_ can do in parallel to make life easier for gitk and gitweb, and it is not on so bare-metal-core side. The latest commit in Paul's "new" branch says:

    We were doing two execs for each tag - one to map the tag ID to a commit
    ID (which git ls-remote was already giving us as refs/tags/foo^{}) and
    one to read the contents of the tag for later display....

I think this is a typical problem any Porcelain layer faces. To grab summary information for all refs in a concise form in one go.

We discussed such a potential command about a month ago with Jakub, but the suggestion did not go anywhere.

http://thread.gmane.org/gmane.comp.version-control.git/25013/focus=25055

In addition to what I described there, such a command should at least allow specifying some special formatting for tag objects, such as dereferencing it once (i.e. what the object name and type of the referenced object is) and dereferencing it repeatedly until a non-tag appears (i.e. "$that_tag^{}" along with its type).

The show-ref command will alleviate the fork+exec problem; the core side update you suggested for ref handling will improve the performance of the implementation of such a command and can be done in parallel.