On Tue, Oct 7, 2014 at 1:25 AM, Patrick Donnelly <batrick@xxxxxxxxxxxx> wrote: > On Thu, Oct 2, 2014 at 12:10 PM, Jeff King <peff@xxxxxxxx> wrote: >> On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote: >>> My understanding is that you are allowed to ask for a SHA1, but most >>> git servers refuse the request. But if you already have the SHA >>> locally, then git doesn't neet to bother asking the server for it, so >>> there's no request to be refused. >> >> That's right. It is the server which enforces the "you cannot fetch an >> arbitrary sha1" rule. >> >> But I think Christian is arguing that the client side should complain >> that $sha1 is not a remote ref, and therefore not something we can >> fetch. This used to be the behavior until 6e7b66e (fetch: fetch objects >> by their exact SHA-1 object names, 2013-01-29). The idea there is that >> some refs may be kept "hidden" from the ref advertisement, but clients >> who learn about the sha1 out-of-band may fetch the tips of hidden refs. >> >> I'm not sure it is a feature that has been particularly well-used to >> date, though. > > There are efforts in the scientific communities at preserving > experimental software and results. One of the things we'd like to do > is shallow clone a specific sha1 commit You're not the first one asking about making a shallow clone from from a specific point. I think the reason fetching from arbitrary sha-1 is not supported is because of security. If we can verify the asked sha-1 is reachable from the visible ref set, then we should allow it. With pack bitmaps, it's getting much cheaper to do such a test. If pack bitmaps are not used, we could set a default/configurable limit, like not traversing more than 1000 commits from any ref for this reachability test). Anybody objecting this approach? -- Duy -- 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