On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote: > >> git show af00f4c39bcc8dc29ed8f59a47066d5993c279e4 > > fatal: bad object af00f4c39bcc8dc29ed8f59a47066d5993c279e4 > >> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4 > > error: no such remote ref af00f4c39bcc8dc29ed8f59a47066d5993c279e4 > >> git fetch origin refs/foo/b1 > > remote: Counting objects: 3, done. > > remote: Compressing objects: 100% (2/2), done. > > remote: Total 3 (delta 0), reused 0 (delta 0) > > Unpacking objects: 100% (3/3), done. > > From https://github.com/chalstrick/dondalfi > > * branch refs/foo/b1 -> FETCH_HEAD > >> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4 > > From https://github.com/chalstrick/dondalfi > > * branch af00f4c39bcc8dc29ed8f59a47066d5993c279e4 -> FETCH_HEAD > > 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. -Peff -- 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