On Thu, Oct 2, 2014 at 12:10 PM, Jeff King <p...@peff.net> 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 from e.g. GitHub. [I think GitHub has this disabled though? I haven't been able to get it to work.] I guess this feature was a step in the right direction but it's not usable AFAIK. Tags are not really suitable as they could change and there are possible namespace issues. -- Patrick Donnelly -- 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
