Re: [PATCH/RFC] Teach repack to optionally retain otherwise lost objects

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 29, 2007, 06:15 UTC
Message-ID: <7vaboxy3va.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <Pine.LNX.4.64.0711290340470.27959@racer.site>

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

Show 6 quoted lines

> 	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.