Jeff King <peff@xxxxxxxx> writes: > On Wed, Jun 05, 2013 at 12:38:23PM -0400, Jeff King wrote: > >> 2. Actually do a reachability check. Doing a full object check to >> allow fetching an arbitrary tree by sha1 is probably prohibitively >> expensive[2], but we could allow the form "<commit>[:<path>]", check >> that "<commit>" is reachable, and then allow arbitrary paths within >> it. > > Thinking on this more, the full reachability check is no worse than what > a clone has to do to fetch the full repository. Here's a series that > does the full check. I'm not entirely happy with the performance, > though; details are in patch 3. For some repository-servers, it may be OK to enable this by default, but I suspect it would be better to have at least an opt-out server configuration. > I think I'd be tempted to just go the more limiting "commit is > reachable" route, instead, which would solve your case (and most sane > cases). Yes, I think that is a reasonable thing to do. After all, as you noted in 4/4, you cannot ask for a single blob, and not being able to ask for a single tree is not much different. > [1/4]: clear parsed flag when we free tree buffers > [2/4]: upload-archive: restrict remote objects with reachability check > [3/4]: list-objects: optimize "revs->blob_objects = 0" case > [4/4]: archive: ignore blob objects when checking reachability > > -Peff -- 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