Re: Replay on arbitrary branches

From: Junio C Hamano <junkio@cox.net>
Date: Sep 3, 2005, 01:47 UTC
Message-ID: <7vwtlydisj.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46a038f905090218113587f64f@mail.gmail.com>

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

Show 6 quoted lines

> 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.

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.