Hello back, just to add something to the letter I just sent with all the details, at the first letter of this thread http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg03883.html
we mentioned this next proposal as a solution to the problem: "So we propose that, for the merge between two branches, it should be calculated through the *shortest path* that (additional condition) goes through the *common ancestor*." We consider that wrong, because the shortest paths involved always include P (P->V and P->M). So, to propose a solution, I'd add the requirement (for the merge/renames case) that the path should start from P to its child, instead that allowing a path from P to the parent of P. And of course, that path never going back to a parent of P. Somehow, forcing a direction from P. Did I express this clear enough? Please ask if it looks uncomprehensible. Regards, Lluís. 2011/5/24 Lluís Batlle <virik...@gmail.com>: > Hello Richard and friends, > In trunk, there are two commits, one child of the other: > e39dfeb63a1d (2011-04-29) child of > 8d4432b6b9 (2011-05-02) > > If I run "test-name-changes e39dfeb63a1d trunk", I get no output. > If I run "test-name-changes 8d4432b6b9 trunk", I get seven filename > changes. These changes *did not* happen in these commits mentioned. > > Do you know how to get this solved? > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users