Thu, 04 Jul 2019 16:55:57 +0200 branching: merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 Jul 2019 16:55:57 +0200] rev 4706
branching: merge with stable
Wed, 26 Jun 2019 21:11:25 +0530 evolve: use right value for branch name when finding branch heads
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 26 Jun 2019 21:11:25 +0530] rev 4705
evolve: use right value for branch name when finding branch heads subbranch already formatted as "branchname:topicname", again appending it with ":topicname" doesn't not make sense. It's a little bit surprising that no tests fails though.
Tue, 25 Jun 2019 21:54:22 +0530 evolve: fix confusion in branch heads checking logic when topic in play
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 25 Jun 2019 21:54:22 +0530] rev 4704
evolve: fix confusion in branch heads checking logic when topic in play To provide some context, when topics are in play the branchmap cache we store contains the branch info of a rev as "branch:topic" format IIUC. Assuming that is right, now in present code we don't actually cover this part that "when looking for branch heads where we also have active topic we should look for branch='branch_name:topic' instead". And we get wrong branch heads as a result. This patch make sure that we pass right candidate to find branch heads using branchmap.branchheads() by overriding the localrepo.branchheads() Changes in test file reflect the fixed behavior.
Sun, 14 Apr 2019 12:55:46 +0530 topic: add tests to demonstrate topic confuses the branchhead checking logic
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 14 Apr 2019 12:55:46 +0530] rev 4703
topic: add tests to demonstrate topic confuses the branchhead checking logic While topics are in play, we store the branchheads (which has a topic) in "branchname:topicname" format. After digging into it I found that even in the case when we should have branch heads for "bname:tname" we get heads for "bname". The tests output reflect the confusion in branch head checking logic. Next patch will be fixing the problem.
Mon, 01 Jul 2019 19:15:57 +0530 evolve: fix the inconsistent behaviour of prune (issue6137) stable
Sushil khanchi <sushilkhanchi97@gmail.com> [Mon, 01 Jul 2019 19:15:57 +0530] rev 4702
evolve: fix the inconsistent behaviour of prune (issue6137) Let's not update to any revision when working directory parent is not related to the revision being pruned. Changes in test file demonstrate the fixed behaviour.
Tue, 02 Jul 2019 21:00:46 +0530 prune: add tests to demonstrate issue6137 stable
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 02 Jul 2019 21:00:46 +0530] rev 4701
prune: add tests to demonstrate issue6137 Here we can see that prune updates off to the parent revision even when the pruned revision wasn't related with the working directory parent. A follow-up patch will fix this.
Sun, 30 Jun 2019 23:50:57 +0530 compat: fix `setupevolveunfinished` for upstream
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 30 Jun 2019 23:50:57 +0530] rev 4700
compat: fix `setupevolveunfinished` for upstream
Sat, 29 Jun 2019 18:21:57 +0800 prune: update to the successor of wdir also with --pair/--biject (issue6142) stable
Anton Shestakov <av6@dwimlabs.net> [Sat, 29 Jun 2019 18:21:57 +0800] rev 4699
prune: update to the successor of wdir also with --pair/--biject (issue6142) When prune is used with --pair flag, we can also update to the successor of working directory parent. No need to check len(sucs) or len(precs) here because there's a check for that earlier in the code (it's a requirement of biject). The tests are now demonstrate the correct behavior: when rev 14 was pruned with 12 as its successor, the bookmark that was on 14 was moved to 12. That bookmark was also activated (even before this patch).
(0) -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 tip