Re: RFC: grafts generalised

Petr Baudis wrote:

On Wed, Jul 02, 2008 at 07:32:03PM +0200, Stephen R. van den Berg wrote:

quoted

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?