Daniel Barkalow <barkalow@iabervon.org> 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 <20050827014009.GB18880@c165.ib.student.liu.se> 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. - 467ca22d3371f132ee225a5591a1ed0cd518cb3d - da28c12089dfcfb8695b6b555cdb8e03dda2b690 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; >>>>>>>>> > } Sounds fine. 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Sep 06 15:43:58 2005
This archive was generated by hypermail 2.1.8 : 2005-09-06 15:44:01 EST