Andreas Gruenbacher <agruen@xxxxxxx> writes:
> No, it's a server side thing.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html