We can try to remove getDirectory() again, but basically the working tree related code explodes.

What matters is, getDirectory() is used to tell you where the meta stuff is, like "index", "config", "MERGE_HEAD", "MERGE_MSG", "FETCH_HEAD".  For most repositories with a working tree, I think you would expect these files to be in .git/, and thus you expect there to be a meta directory to hold them.

Right now I only care about getting a bare repository to run without a local filesystem.  Which means that meta directory being null is OK, we would never check the meta directory.

But to really do a workspace-in-the-cloud idea, you need to also split all of the meta stuff away from local file IO.  That's going to be a bigger task than just splitting the object/ref storage, based on what I was looking at as I did this series.

I'm open to pushing the refactoring further, but I would prefer to get the basic storage stuff done first.  We still need to get IndexPack done for example, it still requires local filesystem storage.  And the dumb transport fetch client also still mostly assumes local filesystem for the destination.

If we at least get the basic storage stuff done, we can start to do something slick like a bound-thin-client in EGit.  The working directory is the local filesystem, but the repository branches and objects are remote on a smart, git-aware object server, with recently accessed objects being local.  Then you can do some really slick thin-checkouts from eclipse.org for example, without needing to suck down everything, but still behave like you have it all.  (I'm envisioning something a bit smarter than just shallow clone.)