Re: [PATCH 2/3] Different views on a repository

Andreas Gruenbacher <agruen@suse.de> writes:

If it were a server side thing, then I would expect no change to send/receive pack. Instead your clients will access distinct URL as if they are different repositories.

    git clone git://example.com/pub/scm/git/A
    git push example.com:/pub/scm/git/B master
    git pull http://example.com/pub/scm/git/C

They should not have to care that the server is cheating to save disk space, and they should be able to access your server with Git v1.6.0.

Instead, the server side would:

 - have separate repositories, A, B and C, as normal repositories;

 - these repositories share their object stores by having their
   .git/objects pointing at a shared location via a symlink;

 - on the server side, gc/prune/fsck will have to be updated so that when
   the object store of a repository (say A) is shared with something else,
   they will consider refs in other repositories (B and C) also as the
   root of traversal.

So if this were a server side solution, I would expect the series would add:

 - a way to set up a shared object store;

 - a way to maintain a list of backlinks to repositories that share an
   object store;

 - a way to create a new repository that shares the object store
   (e.g. create a symlink to the shared store instead of having its own
   .git/objects/, and add itself to the list of backlinks for the shared
   object store);

 - a way to retire an existing such repository (rm -rf and remove itself
   from the list of backlinks);

 - update gc/prune/fsck to honor such a list of backlinks.

This would help a "forks" setup commonly seen at places like repo.or.cz and github.com among others.

One thing that is missing from the above handwaving outline that your "different views" offers is a "consolidated view", a pseudo-repository that allows you to see refs from individual real (from the client's and project participant's point of view) repositories as if they are in individual subhierarchies of the ref namespace.

I however suspect that you didn't want such a view in the first place if there weren't issues around reachability. In other words, I suspect that you invented it merely as one possible solution to the reachability issue, and it was not your goal to have such a consolidated view by itself.