Re: grafts+repack+prune = history at danger

From: Johannes Sixt <j.sixt@eudaptics.com>
Date: Jan 26, 2007, 08:13 UTC
Message-ID: <45B9B80E.E2534F97@eudaptics.com>
In-Reply-To: <7vireu7lj0.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 20 quoted lines

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