# Replay on arbitrary branches

3 messages from 2005-09-03 to 2005-09-03. Participants: Martin Langhoff, Junio C Hamano.
Thread: https://gitlist.dev/t/1720

## Martin Langhoff, 2005-09-03 01:11

Subject: Replay on arbitrary branches
Message-ID: <46a038f905090218113587f64f@mail.gmail.com>
URL: https://gitlist.dev/e/46a038f905090218113587f64f%40mail.gmail.com

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

```

## Junio C Hamano, 2005-09-03 01:47

Subject: Re: Replay on arbitrary branches
Message-ID: <7vwtlydisj.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vwtlydisj.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <46a038f905090218113587f64f@mail.gmail.com>

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

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

```

## Martin Langhoff, 2005-09-03 02:17

Subject: Re: Replay on arbitrary branches
Message-ID: <46a038f90509021917e0833a2@mail.gmail.com>
URL: https://gitlist.dev/e/46a038f90509021917e0833a2%40mail.gmail.com
In-Reply-To: <7vwtlydisj.fsf@assigned-by-dhcp.cox.net>

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

> About 'unrelated' trees, if you know of a good tree you can use

<setup snipped>

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

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

```