Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
> 
> 
>>I've written a tool that will take a single commit, add it as a parent
>>of another commit, and recreate the history above that second commit in
>>a fully compatible manner.
> 
> 
> I think the procedure is reproducible, which is a very nice
> property to have for a tool like this, but I am not sure what
> you mean by "in a fully compatible manner".  What are you
> compatible with?

Well, what I meant was, "It creates a history that is purely a superset
of the old history, so merges should work cleanly from the pre-graft
subhistory to the fully merged history."

But clearly I was too ... terse.

IOW, this should work perfectly, assuming neither tree has been pulled
into since the history was merged into historical-graft tree:

$ cd linux-head
$ git branch -b ryan-hacking HEAD
$ quilt push -a
$ git commit -a -m "Apply quilt tree"

$ cd ../linux-historical-graft/
$ git pull ../linux-historical-graft/

> Also another rhetorical, tongue-in-cheek question.  What is your
> plan to ripple the graft through to update signed tags?  ;-)

:) Well, since I can't resist answering your rhetorical question:

They signed a specific DAG.  I'm providing a richer, more complete DAG
that is a pure-superset of the one they signed.  It is not, however,
equivalent, so their signature is not related to the superset DAG I have
created.  In practice, however, I don't expect that any tag-signers
would state that there is a meaningful difference between the two DAGs,
from the perspective of their signature.

FYI - I don't think merging the trees like this is a good idea, from the
perspective of something like gitk - gitk took long enough to startup
and display something on my merged tree here that I gave up and killed
it off.