Access 'file' view for a blob hash directly

[Google Code Exporter]

This is related to issue 7, but slightly different. Issue 7 enables:
  https://..../path/to/repo/+/<ref>/path/to/blob?format=TEXT

It would also be extremely awesome to be able to do (e.g.):
  https://..../path/to/repo/+blob/<hash>?format=TEXT  # OR
  https://..../path/to/repo/+/<hash>?format=TEXT

IIUC, the naive permission checks for this would be really gnarly, because 
you'd have to walk all accessible refs until you hit a commit with a tree (or a 
chain of trees) which eventually contained the blob.

Talking to dborowitz, however, it seems like it might be possible to re-use the 
object reachability calculation which is normally done on a clone to do this 
check. The object set calculation is apparently implemented with super-fast, 
bitmap-accelerated hyper-algorithmic goodness :).

Original issue reported on code.google.com by [e-mail] on 29 May 2014 at 10:54

[Google Code Exporter]

This is not high-priority, but would enhance the implementation of 
[crbug.com/369329] by providing a simpler access method for the source file 
data (and, I suspect, easier implementation for other similar scripts)

Original comment by [e-mail] on 29 May 2014 at 10:55

[Google Code Exporter]

I couldn't tell by quickly skimming that crbug; is it the case that when you 
need to get the blob text, you don't already have the commit and path?

Original comment by [e-mail] on 29 May 2014 at 10:58

[Google Code Exporter]

That's how we plan to deal with it for now, but being able to just get by blob 
hash would allow interesting alternatives like embedding the blob hash in the 
compiled binary instead of trying to parse and normalize __FILE__, etc.

Original comment by [e-mail] on 29 May 2014 at 11:01

[Google Code Exporter]

(i.e. we have the commit and path on upload, but not necessarily on download)

Original comment by [e-mail] on 29 May 2014 at 11:02

[Google Code Exporter]

(And I want to stress that this is not high-priority, just didn't want to lose 
track of it :)

Original comment by [e-mail] on 29 May 2014 at 11:05