Hello, still with the opened issue http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04716.html , we commited such a 'bad merge' into one of our branches. As there explained, the 'shortest path' used to calculate the renames was clearly wrong.
We decided to go to the previous checkin, merge again, fix manually whatever rename got wrong (we still can handle the amount of renames, luckily), and commit as a 2nd leaf for the branch, for later closing of the broken merge. To our surprise, now the 'shortest-path' goes through the commit *after* the checkin I'm merging into. So, apart from the broken behaviour on renames, should I shun 'bad' commits so merges don't try to use them as shortest paths? I think the problem is in too-much-simplicity of the shortest path algorithm used for the renames on merges. Regards, Lluís. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
