Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

quoted text
> 	Besides, a completely different idea just struck me: before
> 	repacking, .git/objects/pack/* could be _hard linked_ to the
> 	forkee's object stores.  Then nothing in git-repack's code
> 	needs to be changed.
>
> 	Oh, well.  I just wasted 1.5 hours.

Your 1.5 hours was spent wisely to come up with that idea ;-).

To make sure I understand your idea correctly, the procedure to repack a
repository in a fork-friendly way is:

 (1) find the project directly forked from you;

 (2) hardlink all packs under your object store to their object store;

 (3) repack -a -l and prune.

I think that would work as long as you do the above as a unit and handle
one repository at a time.  Otherwise I think you risk losing necessary
objects when hierarchical forks are involved.  E.g.  if you have a
project X that has a fork Y which in turn has fork Z.

	* Step 1 is run for X, Y and Z.
        * Step 2 is run for Y and Z.
        * Step 3 is run for Z.

At this point, Z is still borrowing objects from Y and X through Y, and
it will not keep objects it is borrowing from X through Y.  Then if the
procedure is intermixed like this, a bad thing happens.

	* Step 2 is run for X.
	* Step 3 is run for Y.
	* Step 3 is run for X.

Step 3 for Y would lose objects Y was borrowing from X that were not
used by Y itself.  At this point, Z is still usable as the objects it is
borrowing from X though Y have not been pruned from X.  But Step 3 for X
will lose them, rendering Z unusable.

-
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