Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 29 Aug 2007, Shawn O. Pearce wrote: > > > > Not if I already have a pointer from B to A's refs. repo.or.cz > > also has this same pointer: > > > > git clone --shared A B > > ln -s A/refs B/refs/forkee > > Now, this doesn't work well with packed refs, I'm afraid. No, it doesn't work well. So I actually also avoid packing A's refs. Which is yet another reason why my A's don't allow pushing, that way nobody goes nuts and creates a ton of refs in there. With only refs/heads/master and it being unpacked its not a big deal. > So I suspect that if we really want to support something like this, we'd > need to do more than just avoid the recursion when you cross-link. Yes. I've been thinking about trying to better share the ODB and the ref database between repositories, but it has been low priority for me. I rely on this ref symlinking/alternate ODB trick a lot at day-job to help me cope with an ugly situation I created across a number of repositories. Most of our codebase came from one Git repository, but has been refactored and split into about 10 different Git repositories. I did that refactoring by just cloning and deleting the uninteresting content, so each repository actually has a huge block of its history in common with the other 9. One such A is "common-crap.git" that is the shared common history. Since its strictly history nobody changes that repository, and everyone borrows objects from it. This reduces my common working set by about 900MiB, as the history lives in only one packfile and not in 10. There are obviously other ways to deal with this: - start the 10 repositories over again and use info/grafts to reinsert the old history when/if required; - just hardlink the same .keep'd packfile into the 10 repositories, since it is held by .keep it won't be touched during repack. So one reason it has been low priority for me to improve upon is because there's more than one way to solve the problem, and the particular solution I have settled upon may not be the best solution for anyone. Though I think we can all agree that repo.or.cz's use of forks is increasingly more popular, and one of the more powerful social features of git. Better supporting it out of the box by making it easier to setup and manage can only be a good thing for our users. -- Shawn. - 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
