Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I've got a version of read-tree which accepts multiple ancestors and does
> a merge using information from all of them.
After disabling the debugging printf(), I used this read-tree to
try resolving the parents of four commits Fredrik Kuivinen gave
us in <[EMAIL PROTECTED]> using
their two merge bases, and compared the resulting tree with the
tree recorded in the commit. The results are really promising.
For the following two commits, multi-base merge resolved their
parents trivially and produced the same result as the tree in
the commit. The current "best-base merge" in the master branch
performed far worse and left many conflicts.
Another one, 0e396ee43e445cb7c215a98da4e76d0ce354d9d7,
multi-base merge left only one conflicting path to be hand
resolved. The best-base merge again performed far worse.
The other one, 3190186362466658f01b2e354e639378ce07e1a9, is
resolved trivially with both algorithms.
> 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.
Because? I know it would affect the readers of index files if
you did so, but it would seem the most natural in git
architecture to have merge-cache look at the resulting cache
with such multiple stage 1 entries (and other stages) and let
the script make a decision.
> 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;
Anyway, I really am happy to see this multi-base merge perform
well on real-world data, and you are certainly the git hero of
the week ;-).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html