Re: grafts+repack+prune = history at danger

From: Junio C Hamano <junkio@cox.net>
Date: Jan 25, 2007, 23:07 UTC
Message-ID: <7vireu7lj0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <45B8E61E.C9C5E6C6@eudaptics.com>

Johannes Sixt <J.Sixt@eudaptics.com> writes:

Show 11 quoted lines

> 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, but otherwise the rule of thumb has always been not to expose repositories with grafts without telling unsuspecting downstream people for cloning or fetching. It will give objects they did not even ask for.

grafts are local matter for archaeologist's convenience to glue two independent histories together, and not much more. For example, the history that starts at v2.6.12-rc2 can be grafted on top of old bkcvs history, but people who clone from you may not expect to get anything beyond the true origin of the history at v2.6.12-rc2 (after all that commit object records it as a parentless commit).

I suspect you could extend fetch-pack protocol to give existing grafts from upload-pack to trivially fix 'clone', but I do not know offhand what the ramifications of it are for normal 'fetch'. You would need to merge potentially conflicting graft information you obtained from where you fetched from and what you already had before starting to fetch.