Re: grafts+repack+prune = history at danger

[Johannes Sixt <J.Sixt@eudaptics.com>]

Junio C Hamano wrote:
> 
> Johannes Sixt <J.Sixt@eudaptics.com> writes:
> 
> > Isn't there a major hole in the logic how repack works when grafts are
> > in effect?
> >
> > I did this (details follow):
> >
> > 1. specify grafts
> > 2. repack
> > 3. prune
> > 4. clone
> >
> > Result: Broken history in the clone; info/grafts was not copied.
> 
> That is expected.
> 
> If you had problem in the original repository (i.e. the one with
> grafts) that lost objects after step 3., that would be serious
> and needs to be fixed,

Oh, the original repo *does* loose the object after step 3, but you
would not notice it until you remove the grafts file.

> grafts are local matter for archaeologist's convenience to glue
> two independent histories together, and not much more.

Agreed. Then grafts must be disregarded by (almost) all plumbing, most
notably fsck-objects, prune, pack-objects, but also
{fetch,upload,send,receive}-pack. They should be obeyed only by the log
and diff families and certainly also rev-list on request.

-- Hannes