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

From: Junio C Hamano <junkio@cox.net>
Date: Oct 17, 2005, 20:08 UTC
Message-ID: <7v3bmzzz30.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051017174123.GI5509@reactrix.com>

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.

And we have extended the definition of "available" over time. Initially, you needed to have individual objects, and then we made it so they could live in packs, and now they could even be borrowed from another repository via alternates. We currently do not consider "lazily fetchable over the network" as "available", but I do not object too much to that, as long as it is an optional feature.

This probably is a post 1.0 item, though. Off the top of my head, we would need:

 - a way for the user to say "unless I ask explicitly otherwise,
   do not bother me if the commits older than these ones are
   incomplete" -- an milder version of cauterizing commit chain
   via info/grafts.

 - a way for the user to say "this time I am explicitly
   overriding the above -- I am interested in older history".

 - change to fsck-objects, fetch- and probably upload-pack on
   the other end, and commit walkers to honor the above two.

Most of these can probably be done by existing info/grafts mechanism, but even then definitely would need a nicer user interface.

Once this is in place, range requests to pick data for individual objects from packs residing on a remote HTTP server would start to make sense.