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

From: Junio C Hamano <junkio@cox.net>
To: Nick Hengeveld <nickh@reactrix.com>
Cc: git@vger.kernel.org
Subject: Re: [kernel.org users] Re: auto-packing on kernel.org? please?
Date: Mon, 17 Oct 2005 13:08:03 -0700	[thread overview]
Message-ID: <7v3bmzzz30.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20051017174123.GI5509@reactrix.com> (Nick Hengeveld's message of "Mon, 17 Oct 2005 10:41:23 -0700")

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.