Re: Can I fetch an arbitrary commit by sha1?

Duy Nguyen [off-list ref] writes:

On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:

quoted

Duy Nguyen [off-list ref] writes:

quoted

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.