On Mon, Nov 21, 2011 at 05:09:23PM -0500, Phillip Susi wrote: > I hacked together a setup a few weeks ago that doesn't suffer from > that problem. I had two repos that had considerable shared history ( > one forked from the other ), so I created a temporary repository and > pointed its alternates to the other two. I then did some shell magic > to generate a list of all objects shared by both repos, and sent that > list to git-pack-objects. This gave me a pack file in the temp repo > that contained all of the shared objects. I then made a .keep file > and hard linked this pack file ( and index, and .keep file ) into > both original repos, deleted the temp repo, and then repacked both > original repos. This left them both with two pack files: one that is > shared, and one that is all of the objects specific to that repo. > > Because the shared objects are in a pack file that both repos hard > link to, neither one will break if I (re)move the other. Yes, that is one way to do it. The big drawback there is that by using hard links, you can only share objects between repos within the same filesystem. I think the presence of the '.keep' files should make "git gc" do the right thing, and not waste space. The relinking procedure is a little more complex, but that's not a big deal. It's just a periodic maintenance thing that will happen inside a script (and you would want to do the periodic maintenance as often as you would with the shared repo approach). Nothing is maintaining the list of "here are all of the related repos that are sharing objects". Which is a feature in some ways, because you don't have to care if repos go away or move. But when your periodic "git relink" comes around, the burden is on the user to redecide the set of related repos. So unlike with the shared repo, where "git gc" in a child repo could say "Oh, I have a shared parent; I should go there and do the parent-gc there", relinking would be a more manual thing. On the other hand, nothing is stopping you from building something more automated around this relink-repos-together building block. So yeah, I think it's a perfectly reasonable approach, if you don't mind the hard link requirement, and your relink is something like "git relink ~/linux-repos/*". Patches? :) -Peff -- 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