Re: RFC: grafts generalised

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Jul 3, 2008, 07:11 UTC
Message-ID: <20080703071143.GC27419@cuci.nl>
In-Reply-To: <20080703002117.GH12567@machine.or.cz>

Petr Baudis wrote:

>On Wed, Jul 02, 2008 at 07:32:03PM +0200, Stephen R. van den Berg wrote:
>> Also, the graft mechanism specifically is intended as a temporary
>> solution until one uses filter-branch to "finalise" the result into a
>> proper repository which becomes cloneable.

>Grafts are _much_ older than filter-branch and I'm not sure where did
>you get this idea; do we claim that in any documentation?

Not in direct documentation, but it is what breaths down from posts on the mailinglist like:

http://kerneltrap.org/mailarchive/git/2008/6/10/2085624

Jakub Narebski:

>Then if possible use git-filter-branch to make history recorded in
>grafts file permanent...

Petr Baudis wrote:

>There's nothing ugly or necessarily temporary about grafts. One example
>of completely valid usage is adding previous history of a project to it
>later.

>First, you don't need to carry around all the archived baggage you are
>probably rarely going to access anyway if you don't need to; changing a
>VCS is ideal cutoff point.

That depends on the project, of course, and is not a valid statement in general. Part of the charm of full history is that git-blame and git-bisect work, at arbitrary points in the past.

>Second, you don't need to worry about doing perfect conversion at the
>moment of the switch.

Well, you do, if you intend to make it cloneable.

>Third, even if you think you have done it perfectly, it will turn out
>later that something is wrong anyway.

Not necessarily. I have automated the checkout-verification-process which basically checks out every revision from the respective old repository and binary-compares it with the corresponding revision in the git repository. This ensures a full binary match across the board. With respect to historical merges, I agree, those might not be completely correctly grafted, but the level of correctness can be determined at will, and once we achieve somewhere around 99% accuracy, we consider it done (for this project).

>Fourth, it may not be actually _clear_ what the canonical history should
>be.

That depends on the project. In my project it *is* clear, so this point doesn't make any difference.

-- 
Sincerely,
           Stephen R. van den Berg.

This is a day for firm decisions!  Or is it?