Combining history of two branches

[Tom Widmer]

Matt Mackall wrote:
> On Tue, May 05, 2009 at 04:28:43PM -0400, Greg Ward wrote:
>> On Tue, May 5, 2009 at 8:08 AM, Tom Widmer <tom.widmer at googlemail.com> wrote:
>>> I have two unrelated (in HG terms) repositories:
>>> X (77MB) has 500 revisions, 4 named branches (all branched after r10)
>>> Y (466 MB) has 20000 revisions, completely linear history (no branches
>>> or merges)
>>>
>>> The tip of Y has an *identical* working tree to X at 10.
>>>
>>> I want to create a new repository Z. Z will replace X1..10 with the much
>>> more exciting history of Y1..20000, thus allowing log and annotate to
>>> provide the full, rich history, rather than the truncated version from
>>> X. How do I create Z? In effect, I have to replay X11..500 on top of Y.
>> Have you tried simply pulling from X into Y?  You'll need "pull -f"
>> because they are unrelated repositories, but that's definitely the
>> place to start.

Having the changesets in the same repository is one thing, having a 
coherent linear history is another. Simple merges don't help in this 
case - I really am trying to change history, splicing the revisions in Y 
into the history of X.

>>> Will MQ allow me to do this (noting that the repositories are
>>> unrelated)? Can it cope with the 4 named branches that need to be
>>> replayed, or I need to split things up into multiple repositories first?
>>> How?
> 
> MQ assumes linear history on the 'new' side, so no, this won't work.
> 
>> I do not think that MQ (or rebase for that matter) are relevant.  MQ
>> and rebase are fundamentally history editing tools.  You're not
>> editing history, you're merging two repositories.  You can do that
>> with pull, or with export/import, or with bundle/unbundle.
> 
> Actually, rebase might work. If you pull -f the two histories into a
> combined repo, you can rebase the new history onto the old.

Experimenting, there seem to be problems with rebase when the source 
revision has multiple head descendents - I think it may be a bug.

> The transplant may also be useful here, as might convert (you can
> trick it into grafting history by seeding its shamap).

Thanks for the hint. For the record, this seems to work:
hg convert --splicemap join.map reposX repoY
works a treat, with join.map just containing:
<X at 11 full revision hash> <Y tip full revision hash>

(this effectively tells the repo that the parent of rev 11 is the tip of 
our long 20000 rev history, and not rev 10)

Thanks very much,

Tom