Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
