Re: [kernel.org users] Re: auto-packing on kernel.org? please?

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 17, 2005, 22:56 UTC
Message-ID: <Pine.LNX.4.63.0510171830030.23242@iabervon.org>
In-Reply-To: <7v3bmzzz30.fsf@assigned-by-dhcp.cox.net>

On Mon, 17 Oct 2005, Junio C Hamano wrote:

Show 19 quoted lines

> Nick Hengeveld <nickh@reactrix.com> writes:
> 
> > Gotcha - I'm still thinking in terms of content distribution, where
> > you only need a specific version of a tree to be available locally
> > and explicitly don't want to transfer history.
> 
> In other words, you'd want to also support CVS-like "working
> tree has the specific version, and history is not kept here, but
> available on demand, possibly over the network" mode of
> operation.  I'd say why not.  We could aim to have "working tree
> has the specific version and partial history of recent versions,
> and the ancient history is available on demand, possibly over
> the network" mode of operation.
> 
> It is somewhat different from the primary focus of what we have
> been doing, but I think it is a natural extension.  The
> invariant is that once you have a ref pointing at a specific
> commit, everything reachable from it ought to be available to
> you.

Wouldn't "git fetch http://.../foo.git/ master^{tree}" do the right thing?

You get only the current tree, and write a ref to the tree instead of the commit, maintaining the invariant. Of course, fetch.c needs a bit of work so that it can fetch objects in the process of figuring out what the refspec that it's really trying to fetch, but that should be simple enough.

Of course, this really isolates you from the history, since you don't even remember what the commit was that you've got the tree from, but that may not be an issue in a pure content distribution setup. Also, a pack file of a single tree isn't going to be terribly efficient, because pack files mostly exploit the high similarity between different versions of the same file.

My other idea is to have a file of things that you expect to be missing, even though they are referenced, and where to expect to find them if necessary. Then you could download the latest commit, mark its parents (unless you have them) as known-missing, and write the ref.

	-Daniel
*This .sig left intentionally blank*