All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Anderson <ryan@michonline.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Applying a graft to a tree and "rippling" the changes through the history
Date: Sun, 06 Nov 2005 21:22:33 -0500	[thread overview]
Message-ID: <436EBA69.6000900@michonline.com> (raw)
In-Reply-To: <7vll01ut6j.fsf@assigned-by-dhcp.cox.net>

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

  reply	other threads:[~2005-11-07  2:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-06 22:38 [RFC] Applying a graft to a tree and "rippling" the changes through the history Ryan Anderson
2005-11-06 22:43 ` Randal L. Schwartz
2005-11-07  1:45 ` Junio C Hamano
2005-11-07  2:22   ` Ryan Anderson [this message]
2005-11-18  8:49   ` Matthias Urlichs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=436EBA69.6000900@michonline.com \
    --to=ryan@michonline.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.