Re: RFC: grafts generalised

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

Jakub Narebski wrote:
>First, if I remember correctly (from KernelTrap and now defunct Kernel
>Traffic and one issue of Git Traffic) the 'graft' mechanizm was
>created so it would be possible to "graft" (join) historical
>conversion repository with the "current work" git repository (started
>from zero when git was deemed good enough for Linux kernel
>development).

Quite.  Which is exactly the spirit I'm extending here.
I need it to stitch together history, but it needs to be more perfect
than mere connecting parents.

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.

>The fact that git-filter-branch (and earlier cg-admin-rewrite-hist)
>respects grafts, and rewrites history so that grafts are no-op and are
>not needed further is a bit of side-effect.

I beg to differ.  It's not a side effect, it's the proper way to get
rid of the grafts file.  Grafts are temporary and ugly.  In proper
repositories they are a sign of transition to a proper state.
The proper state is attained by using git filter-branch.

>  So I think that it would
>be better to provide generic git-filter-branch filter which can
>understand this "generalized grafts" file format, or rather
>'description of changes' file.  Put it in contrib/, and here you
>go...

The problem is that the process of fixing history is an iterative one,
which can take many months, and everytime you make a change, the
correctness needs to be viewed using gitk.

For argument sake, consider the repository at hand which I'm trying to
"fix", it has 33000 commits, distributed over eight branches with
roughly 3500 merges over a timeperiod of 13 years.
The eight branches were eight separate CVS repositories which have
intersecting histories, and 3500 merges between CVS repositories (i.e.
branches).

If I need to backpatch a certain patch into history, it is likely that
in order to let the change ripple through, it will take 20000 commits to
be rewritten every time I make a slight change to history.
It's not really workable to ripple through 20000 commits everytime I
make a historical change, yet I need to view the change in gitk.

Using git filter-branch, or git sequencer basically has the same
problem, I need to ripple through most of history to get to a state
which is viewable using gitk again.  That is too long a turnaround
cycle.

Using the proposed grafts format, I can make changes incrementally, and
immediately viewable (though not cloneable) on the local repository using gitk.
Then after making all the necessary changes, one git filter-branch run
will "burn" the changes into the repository proper in one go
(renumbering all tags, branches and merges along the way).
-- 
Sincerely,
           Stephen R. van den Berg.

You are confused; but this is your normal state.