Multi-ancestor read-tree notes

I've got a version of read-tree which accepts multiple ancestors and does 
a merge using information from all of them.

The basic features are that it looks for an ancestor which would permit a 
trivial merge, and uses that. However, if it finds ancestors which permit 
different trivial merges, it does not merge (which I call case #16).

In case #16, I'm not sure what I should produce. I think the best thing 
might be to not leave anything in stage 1. The desired end effect is that 
the user is given a file with a section like:

  {
    *t = NULL;
    *m = 0;
<<<<<<<<
    return Z_DATA_ERROR;
========
    return Z_OK;

quoted

quoted

quoted

quoted

quoted

quoted

quoted

  }

In other news, the merge that was giving Len Brown problems a while ago 
turns out to have the above conflict, and he happened to end up doing the 
right thing and not reverting Linus's revert of an unnecessary (but 
harmless) change. I only noticed this just now, when I was testing that 
merge, and got it to generate only two conflicts regardless of order of 
ancestors (didn't try to resolve the other one, drivers/acpi/osl.c, with 
"merge" either way).

So this test is encouraging: I get fewer non-trivial cases than either of 
the ancestors alone gives, and I catch a case that both single ancestors 
gets wrong.

Note that there are still some memory leaks for me to fix, but that's the 
only flaw I know of with this.

Patches against mainline to follow shortly.

	-Daniel
*This .sig left intentionally blank*

On Mon, 2005-09-05 at 01:41 -0400, Daniel Barkalow wrote:

I've got a version of read-tree which accepts multiple ancestors and does 
a merge using information from all of them.

Do the multiple ancestors have to share a common parent? More to the
point, is this read-tree any more friendly to baseless merges?

--
Darrin

On Thu, Sep 08, 2005 at 12:16:05PM -0500, Darrin Thompson wrote:

On Mon, 2005-09-05 at 01:41 -0400, Daniel Barkalow wrote:

quoted

I've got a version of read-tree which accepts multiple ancestors and does 
a merge using information from all of them.

Do the multiple ancestors have to share a common parent? More to the
point, is this read-tree any more friendly to baseless merges?

Is a baseless merge a merge with two branches that do not have a
common ancestor? That is, if we want to merge the branches A and B and
git-merge-base --all A B do not return any commits, is that a baseless
merge?

If that is the case then my merge code handles baseless merges
fine. Or, it is _supposed_ to handle them, I have done some basic
tests but it hasn't been tested thoroughly yet.

I don't know how the new read-tree code handles those cases.

- Fredrik

On Thu, 8 Sep 2005, Darrin Thompson wrote:

On Mon, 2005-09-05 at 01:41 -0400, Daniel Barkalow wrote:

quoted

I've got a version of read-tree which accepts multiple ancestors and does 
a merge using information from all of them.

Do the multiple ancestors have to share a common parent? More to the
point, is this read-tree any more friendly to baseless merges?

read-tree doesn't care about the relationships between its inputs; it's 
only interested in the trees. But using ancestors which aren't common is 
unlikely to give you desired results. I think, if you do read-tree a^ b^ a 
b, you will get everything into the index, but it'll all going to be 
conflicts.

I assume that what you want is something to include everything from two 
commits, which would give conflicts if a name is reused?

	-Daniel
*This .sig left intentionally blank*

On Thu, 2005-09-08 at 17:39 -0400, Daniel Barkalow wrote:

I assume that what you want is something to include everything from two 
commits, which would give conflicts if a name is reused?

Yes.

--
Darrin