Your question is essentially a duplicate of Retrieve specific commit from a remote Git repository for which VonC's answer is essential. But I was a bit curious so I poked around, and wrote this up.
For various reasons both good and bad, the Git transfer protocol used by git fetch usually does not allow you to specify raw hash IDs. (The essential restriction is that it's the other Git, the one you call up on the Internet-phone by running your Git, that controls the name-to-ID mappings that you are allowed to see. They may allow you to use raw hash IDs, as in VonC's answer, but that's up to them and requires that they explicitly enable the feature.)
What this means in practice is that to git fetch some particular commit, even if you know its hash ID, you must know or discover some name from which the commit is reachable. If these were all in your own Git repository, you would do this by running:
git branch --contains <hash>
and:
git tag --contains <hash>
to see which branch and/or tag names "reach" the commit, i.e., starting from those branch or tag names while running a graph-walking command like git log, eventually the commit you care about would show up.
Of course, the problem with this is that you don't have that commit. It's that other Git that has that commit. So you must convince them to do this for you. You must get them to tell you which name or names will reach the commit. Or ... well, let's save this for a moment.
According to How to tell which branch a github commit was for? the display page that GitHub shows now automatically includes a name that reaches the commit, unless the commit is reachable from the default branch. When I click your link I see no name, which implies that it is on the default branch. But that contradicts this:
When I gitcloned this repository, I can't see this commit.
So I tried cloning it myself, and indeed, it is not in my clone either—which tells us that it is not in fact on the default branch. If it were, it would be in the clone, since the clone clones all exposed branches and tags.
In other words, GitHub's claim that we see which branch contains the commit, when we view the page through the web interface, is ... well, maybe not a lie, but at least too strong.
So where is it?
Now we may wish to bring out the Big Hammer: a mirror clone. A mirror clone is a form of --bare clone, where you get no work-tree at all, but it also modifies the fetch refspec so that you get every reference, not just branches and tags. (This is a pretty big repository, so I actually just converted my existing clone to a fetch mirror.1) GitHub uses a bunch of unusual references, stored in refs/pull/ and refs/reviewable/ name-spaces. Perhaps our commit is buried in one of these.
Converting the clone to a mirror and re-fetching brought over a lot more commits—there are 6140 "pull request" name-space items and 2557 "reviewable" items—but commit f28cd62519f071dce69efc0bee4b20a849ae3dea is still not among them. It is, in fact, nowhere to be found.
There are some more clues here though: it's a revert of another commit, d12cc39826791220987b6df2a91cbedaae4d8264, also accessible through GitHub's web interface (click on the commit it claims to revert). d12cc39... is f28cd62519f071dce69efc0bee4b20a849ae3dea's immediate parent as well; and d12cc39..., too, does not appear in the mirror clone—but d12cc39...'s parent, 5d1db5d717d22339b498c24d5a3206743dbe68f1, is in both master and stable.
So, given that we have 5d1db5d7... in our clone, but neither d12cc39... nor its subsequent revert f28cd62..., it seems likely that this is what happened:
- The author wrote a commit and submitted it for review.
- The author realized the commit was wrong and added a revert to the review.
- The author then realized that changing something, then changing it back immediately, is kind of pointless, and retracted the review. There is now no name by which these two commits can be reached.
- However, GitHub had already decided to allow web access to the two commits, and has yet to revoke said web access to these two no-longer-clone-able (in any way at all) commits.
In the end, then, this means you cannot get those two commits into your own repository—but there is no reason to bother; the author has retracted them as the revert was for something that was never added because it was (probably) wrong.
1In fact, I cheated and used --fetch-head-ok to fetch into a non-bare hand-built fake fetch mirror. You are not supposed to do this; it's not normally a good idea; it's a bit like checking whether the power is on by throwing a lot of sparks. You might set fire to something if you don't know what you're doing. :-)
