Hi,

On Wed, 28 Nov 2007, Junio C Hamano wrote:

quoted text
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ;-).

Thanks ;-)

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

Yep.

quoted text
> I think that would work as long as you do the above as a unit and handle
> one repository at a time.

Exactly.  See

http://repo.or.cz/w/repo.git?a=commitdiff;h=fba501deabd349afbe3b8bf89f385889889e04ac

for a tired proposal.

Note that "prune" is not (yet) an option, since it could possibly destroy 
objects which are needed in an ongoing push operation.

However, we could do exactly the same as with reflogs: introduce a grace 
period (with loose objects, we can use the ctime...)

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

Well, in theory you could also iterate over all projects and hard link the 
packs/objects of their alternates, and _then_ iterate and repack.  But it 
is simpler and more obvious in the case of repo.or.cz to do all in one 
iteration, because we can order the repository names easily so that 
forkees come first, _and_ we have an easy way to find out what are the 
forks of a project.

Ciao,
Dscho

-
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