Re: [PATCH] Enable and fix support for base less merges.

From: Fredrik Kuivinen <freku045@student.liu.se>
Date: Oct 5, 2005, 20:32 UTC
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:

Show 6 quoted lines

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

Show 11 quoted lines

> 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