Re: [PATCH] archive: re-allow HEAD:Documentation on a remote invocation

From: Jeff King <peff@peff.net>
Date: Jan 11, 2012, 19:39 UTC
Message-ID: <20120111193916.GA12333@sigill.intra.peff.net>
In-Reply-To: <1326283958-30271-1-git-send-email-cmn@elego.de>

On Wed, Jan 11, 2012 at 01:12:38PM +0100, Carlos Martín Nieto wrote:

Show 9 quoted lines

> The tightening done in (ee27ca4a: archive: don't let remote clients
> get unreachable commits, 2011-11-17) went too far and disallowed
> HEAD:Documentation as it would try to find "HEAD:Documentation" as a
> ref.
> 
> Only DWIM the "HEAD" part to see if it exists as a ref. Once we're
> sure that we've been given a valid ref, we follow the normal code
> path. This still disallows attempts to access commits which are not
> branch tips.

I'd rather not do this kind of ad-hoc parsing of sha1s in the archive code, and instead let the regular resolution process tell us more about what it did, so we can make a policy decision at the upper level.

Patches to follow:

  [1/2]: get_sha1_with_context: report features used in resolution
  [2/2]: archive: loosen restrictions on remote object lookup

> AFAICT this should still be safe. Using HEAD^:Documentation or
> <sha1>:Documentation still complains that HEAD^ and <sha1> aren't
> refs.

My patches enable things like HEAD^, but disallow a raw sha1. The only way to safely allow a raw sha1 is to check its connectivity from the tips, which can be somewhat expensive (you have to traverse every tree of every commit in the worst case).

-Peff