Replay on arbitrary branches

Is there a way to replay a merge on a head that GIT considers unrelated? 

I have been playing with exporting to mbox format with git-format-patch-script, and applying those to the destination branch. However, this drops binary files -- and I _do_ have binary files in some of the projects I work on.

cheers,

martin

Martin Langhoff <martin.langhoff@gmail.com> writes:

I do not think your question has much to do with 'GIT considers unrelated'. The 'git resolve' machinery would have the same problem with related trees, if you do keep track of binary files, and you are changing them in both branches. The 3-way merge resolution step will eventually invoke 'merge' or 'diff3' and you lose.

About 'unrelated' trees, if you know of a good tree you can use as a reference point, you could manually emulate what 'git resolve' does. Let's say you have project A and project B; for whatever historical reasons you do not have a common ancestor of these project master branch heads.

    $ git clone projectA/.git merged
    $ cd merged
    $ git fetch ../projectB/.git master:b

Now refs/heads/master is projectA's head, and refs/heads/b is projectB's. They may not be related, but if you know a commit c that was in some shared past from both projects, you probably can:

    $ git-read-tree -m -u c master b
    $ git-merge-cache -o git-merge-one-file-script -a

If the resulting tree looks reasonable, you could now commit it telling 'git-commit-tree' that the parents of the new commit are master and b, and you practically merged two projects.

Agreed on the impossibility of 3-way merges with binary files. In the branch I want to replay, though, I have commits that add and change binary files.

<setup snipped>

Cool! I think this is what I was looking for. The call to git-read-tree will act as if A and B had branched off at tree "C". I'll have to read the doco on git-read-tree and git-merge-cache a bit more to feel comfortable with this voodoo, but it's great.

cheers,

martin