Optional reachability checks for direct object access

[Konstantin Ryabitsev]

Hi, all:

It is common for git hosting environments to configure all forks of the 
same repo to use an "object storage" repository. For example, this is 
what allows git.kernel.org's 600+ forks of linux.git to take up only 
10GB on disk as opposed to 800GB.

One of the side-effects of this setup is that any object in the shared 
repository can be accessed from any of the forks, which periodically 
confuses people into believing that something terrible has happened.  
Case in point:

https://github.com/torvalds/linux/blob/b4061a10fc29010a610ff2b5b20160d7335e69bf/drivers/hid/hid-samsung.c#L113-L118

Now, this could be fixed by performing reachability checks, but they are 
expensive, so it makes sense to have this off in most cases. However, I 
think it would be a nice feature to be able to enable this 
per-repository -- for example, to avoid someone getting confused when 
they see odd objects in what would appear to be the official Linux 
repository.

Git-upload-pack implements this, which is why it's possible to set 
uploadpack.allowReachableSHA1InWant 
(https://git-scm.com/docs/git-config#Documentation/git-config.txt-uploadpackallowReachableSHA1InWant).  

The easiest way to check if an object is reachable from a repository 
that I can think of is to run "git branch --contains [commit-id]" and 
checking if anything is returned. E.g., a commit 
184c79e4acf5a55f1d6febcf4cf1b545880c2fde doesn't exist in 
torvalds/linux.git, but git finds it just fine through alternates:

  $ git cat-file -t 184c79e4acf5a55f1d6febcf4cf1b545880c2fde
  commit

And you can access it via cgit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=184c79e4acf5a55f1d6febcf4cf1b545880c2fde

However, it doesn't exist in that tree:

  $ git branch --contains 184c79e4acf5a55f1d6febcf4cf1b545880c2fde
  $

If cgit could optionally perform this (or similar) check and return 404 
if a repo is configured to only display reachable objects, that would 
help avoid confusion. Afaict, it's not even that expensive when 
commit-graphs are regularly built. For example, the above check only 
takes 0m0.034s of sys time, according to "time".

What do you think?

-K