From: Fredrik Kuivinen <freku045@student.liu.se>
Date: Wed, 05 Oct 2005 20:32:30 GMT
Subject: Re: [PATCH] Enable and fix support for base less merges.
Message-ID: <20051005203230.GB1833@c165.ib.student.liu.se>
In-Reply-To: <46a038f90510032322t6623c8d4y969e4e00bf4dfe26@mail.gmail.com>

On Tue, Oct 04, 2005 at 07:22:04PM +1300, Martin Langhoff wrote:
> On 10/4/05, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> > I don't really understand what you mean. In what way could git-apply
> > use this? Is there a specific use case you are thinking about?
> 
> Hmmm, perhaps I'm not understanding what a 'base less' merge is.
>

A base less merge is a merge of two branches which do not have a
common ancestor. That is, git-merge-base --all branch-A branch-B will
not return any results.

> Lately, I've been doing some "merges" where there was no common
> ancestor (known to git) and doing some lightweight cherrypicking by
> using `git-format-patch --mbox -o tmpdir` and then using
> git-applymbox. This is very useful to "replay" history against a
> different git repo (or branch) that doesn't share a common ancestor.
>
> But this has no support from the new smart merging mechanisms, which
> could potentially help by applying a patch to a renamed file. I'm not
> sure whether the "recursive" strategy needs 2 parents to figure this
> out, but if it doesn't, this'd be interesting to have. But at the time
> git-apply is cold, limited and unhelpful.

A base less merge is handled exactly as if there was a common ancestor
for the two branches with an empty tree. Renames are detected by
executing git-diff-tree -M --diff-filter=R -r <common ancestor>
<branch-A> and the analogous command for <branch-B>. Hence, if <common
ancestor> corresponds to an empty tree no renames will be detected.

I guess the major difference between cherrypicking with
git-format-patch and merging is that a merge is pretty much an all or
nothing thing. If you merge a branch you will get every commit from
that branch (and if you don't merge you will obviously not get any
commits at all).

> If baseless merges support what I am doing without resorting to
> patches, I'd be a really happy camper. Using mbox patchruns sucks,
> thank you very much for asking, because they don't support binary
> files.

It's unfortunate that binary files aren't supported. I have been
thinking about doing something about it, there isn't any code yet
though.

Anyway, the idea I have thought about is to use (probably
base64-encoded) xdelta diffs for the binary files. With this approach
git diffs could look like:

diff --git --xdelta a/foo b/foo
<base64-encoded xdelta data>

Is this approach reasonable?

- Fredrik