2011/6/1 Lluís Batlle i Rossell <[email protected]> > Hello, > > still with the opened issue > http://www.mail-archive.com/[email protected]/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. >
Can you send me the repo file? > > 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 > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
