Subject: Re: Can I fetch an arbitrary commit by sha1?

From: Junio C Hamano <[email-masked]>
Date: Thu, 09 Oct 2014 11:08:06 -0700

Duy Nguyen <[email-masked]> writes:

> On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:
>> Duy Nguyen <[email-masked]> writes:
>> 
>> > Hmm.. Junio already did most of the work in 051e400 (helping
>> > smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to
>> > do is enable uploadpack.allowtipsha1inwant and apply this patch
>> 
>> Not that patch, I would think.
>> 
>> I would understand "if !stateless_rpc and !allowtipsha1 then it is
>> an error", though.
>
> Fair enough. It seems to work, technically, using the patch below. But
> I think people would rather have support from "git clone" and "git
> clone --branch" can't deal with SHA-1 this way yet. And --branch might
> be a bad place to enable this..
>
> So it needs more work.

This is so non-standard a thing to do that I doubt it is worth
supporting with "git clone".  "git clone --branch", which is about
"I want to follow that particular branch", would not mesh well with
"I want to see the history that leads to this exact commit", either.
You would not know which branch(es) is that exact commit is on in
the first place.

I would not say that "git archive" is sufficient, however, as "I
want to see the history that leads to the commit" is different from
"I want to grab the state recorded at that commit".

The "uploadpack.allowtipsha1inwant" is a wrong configuration to tie
this into.  The intent of the configuration is to allow *ONLY*
commits at the tip of the (possibly hidden) refs to be asked for.
Those who want to hide some refs using "uploadpack.hiderefs" may
want to enable "allowtipsha1inwant" to allow the tips of the hidden
refs while still disallowing a request to fetch any random reachable
commit not at the tip.

The "check_non_tip()" hack is a work-around for the deficiency of
the smart HTTP protocol (the tips of the refs the client reads off
of the server end are not the tips of the refs the serving server
verifies against the request due to information loss between the two
processes at the server end), and is not necessary for the proper
Git transport, where the server who first grabbed its tips of refs
and advertised them will know what it advertised and can expect the
request to come back asking exactly for those refs, not random
ancestors of those refs.

This new feature needs to be enabled with a different configuration
variable, perhaps "uploadpack.allownontipsha1inwant".  It has
associated cost of having to walk back the history to check the
reachability.

Thanks.