Re: [RFC/PATCH 0/4] real reachability checks for upload-archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]