Re: RFC: grafts generalised

["Stephen R. van den Berg" <srb@cuci.nl>]

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?