Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone

From: Petr Baudis <pasky@suse.cz>
Date: Jul 24, 2008, 18:53 UTC
Message-ID: <20080724185332.GQ32184@machine.or.cz>
In-Reply-To: <alpine.DEB.1.00.0807241837441.8986@racer>

Hi,

On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:

Show 17 quoted lines

> On Thu, 24 Jul 2008, Jeff King wrote:
> 
> > As a user, I would expect "sparse clone" to also be sparse on the 
> > fetching. That is, to not even bother fetching tree objects that we are 
> > not going to check out. But that is a whole other can of worms from 
> > local sparseness, so I think it is worth saving for a different series.
> 
> I think this is not even worth of a series.  Sure, it would have benefits 
> for those who want sparse checkouts.  But it comes for a high price on 
> everyone else:
> 
> - security issues (you'd need to open the git protocol to give you 
>   something else than a ref, _including_ refs that were deleted)
> 
> - performance issues (the server would have to do a lot more, faking 
>   commits, or in the alternative serving a gazillion more sessions if the 
>   client does the reconstruction)

  I don't follow how these two issues arise, if the server will do the
pruning for you. It will just skip entering some tree objects when doing
object traversal; why opening the git protocol or faking commits? This
would be a simple extra capability in the protocol.

  One question is what to do with delta chains including unwanted
objects, but I think that given the objects' associativity for delta
chains, this shouldn't be huge practical issues and it could be
affordable in principle to include even unwanted objects.

> ... and I am sure there are tons more issues.

  I do agree on this. :-)

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie