Thread (16 messages) flat view 16 messages, 7 authors, 2016-06-15

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

From: Petr Baudis <hidden>
Date: 2016-06-15 22:45:00

  Hi,

On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
On Thu, 24 Jul 2008, Jeff King wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help