Multi-ancestor read-tree notes
From: Daniel Barkalow <hidden>
Date: 2016-06-15 22:42:05
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*