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

On Tue, Oct 04, 2005 at 07:22:04PM +1300, Martin Langhoff wrote:

On 10/4/05, Fredrik Kuivinen [off-list ref] wrote:

quoted

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