Let's say we start with this history: o c | o a+b | o p Then split a+b into two commit and prune b, so we have this: x b | o a | | o c | | | x a+b |/ o p If we now evolve c, it will be moved on top of p. I would expect it to land on a.
Bug was inactive for 150 days, archiving
I haven't checked if this has been fixed. I'll let the evolve developers mark it as fixed if it has been.
I'm not sure this is fully fixed, we'll have to check.
Fixed by https://mercurial-scm.org/repo/hg/rev/191fac9ff9d3 Sushil khanchi <sushilkhanchi97@gmail.com> obsutil: fix the issue5686 While traversing the obsolescence graph to find the successors sets of csets: In its 4th case (read comments of obsutil.successorssets to see all 4 cases) where we know successors sets of all direct successors of CURRENT, we were just missing a condition to filter out the case when a cset is pruned. And without this condition (that this patch added) it was making a whole successor set to [] just because of one pruned marker. For e.g:if following is the successors set of a cset A: A -> [a, b, c] if we prune c, we expect A's successors set to be [a, b] but you would get: A -> [] So this patch make sure that we calculate the right successorsset of csets considering the pruned cset (in split case). Differential Revision: https://phab.mercurial-scm.org/D5474 (please test the fix)
Bug was set to TESTING for 7 days, resolving