hi, Junio C Hamano <gitster <at> pobox.com> writes: > The "alternates" mechanism [...] sorry for the somewhat late response - i found this thread only now. at qt-project.org we have a somewhat peculiar setup: we have the qt4 repository, and a bunch of qt5 repositories which resulted from a split. qt5 is under active development, but qt4 is still maintained. that means that we need to cherry-pick between those repositories quite a lot. for an optimal cherry-picking experience one needs three-way-merging, which means we need shared object stores. which is where the problems start: my first approach was just a common objects/ directory with all repositories symlinking into it. problems: - the object store can never be garbage-collected. with a lot of heavy rebasing and temporarily added remotes, it gets messy after a while. - there is a constant risk of destroying the object store by inadvertently running git gc - which is particularly likely with git-gui, as it seems to be retarded enough to ignore the auto-gc setting. so the second approach is the "bare aggregator repo" which adds all other repos as remotes, and the other repos link back via alternates. problems: - to actually share objects, one always needs to push to the aggregator - tags having a shared namespace doesn't actually work, because the repos have the same tags on different commits (they are independent repos, after all) - one still cannot safely garbage-collect the aggregator, as the refs don't include the stashes and the index, so rebasing may invalidate these more transient objects. i would re-propose hallvard's "volatile" alternates (at least i think that's what he was talking about two weeks ago): they can be used to obtain objects, but every object which is in any way referenced from the current clone must be available locally (or from a "regular" alternate). that means that diffing, etc. would get objects only temporarily, while cherry-picking would actually copy (some of) the objects. this would make it possible to "cross-link" repositories, safely and without any "3rd parties". thoughts? regards -- 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