On 11/14/2011 5:34 AM, Jeff King wrote:
One issue with this scheme (or most similar schemes) is that child repos are uniquely identified by their directory name. In the absence of alternates, it's perfectly reasonable to do: git init; hack hack hack; commit commit commit cd .. ; mv project new-project-name but here it would break the shared repo's link to the child (which is not just inconvenient, but dangerous, as we will not respect its refs when pruning). Probably the "warning" above should actually error out and force the user to say "yes, I deleted this child" or "no, I moved it here".
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. It would be nice if git relink could be enhanced to do this, then you can just periodically run relink with a list of repos and it could hard link all of the shared data into a big shared pack file, with no need to have a "master" repo that requires special handling.
-- 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