Duy Nguyen <pclo...@gmail.com> writes: > On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote: >> Duy Nguyen <pclo...@gmail.com> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
