Hi, On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
