Linus Torvalds <torvalds@linux-foundation.org> wrote:
quoted text
> 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.
 
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html