Hello I have a big bare repository 'main.git' and many small git repositories sub1, sub2, ... subn. All repositories lie in the same file file system, and each subx repository track and fetch main.git in a remote branch. I would like to avoid duplicating main.git objects, I have made some tries: - Putting a hard link to the pack in the object repository of main.git into subx object repository before fetching the main.git remote. It works well... until the first repack on either side. Note that the problem is the same for any clone of a local repository, the hard link of packs vanish on the first repack. You end up with a pack with the same objects, and so the same name, but organized in a different way so with an associated idx file and often a different file size. - Using an objects/info/alternates with the path of main.git object repository. It work well too, but I import objects from main.git inside subx, and they don't have the same life time than those in main.git. So they can, disapear during a git-prune-packed or gc. (The same problem we have with: git clone --share) - I tried also to use git-relink to synchronize diverging repositories. But git-relink see different packs with the same name, (because repacked in a different way) and refuse to hard-link the packs but hard-links the .idx which has also an identical name and had the same size in my experiments. So the .idx does no longer agree with the .pack and git fsck fail. Of course we can recover the repository by generating a new idx, but git-relink is a dangerous tool to use here. If we unpack all objects we have not all these problems, but the main.git is in this case quite big. Of course it may be better to have a big repository than 20 copies of the packed repository. But I suppose that that there is some way to share an object repository in a safe way, even if it includes some packs. I am quite new to git core and internals, so I may have missed the point. Marc -- 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
