Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Nov 2018 02:18:58 +0000] rev 4260
compat: drop 4.3 wrapping of createmarker for effect flag support
This is supported natively in 4.4 and above.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Nov 2018 01:52:45 +0000] rev 4259
compat: drop 4.3 monkey patch of `copies.mergecopies`
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Nov 2018 01:45:34 +0000] rev 4258
compat: drop 4.3 compatiblity code for `obsutil.allprecursors` function
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Nov 2018 01:44:28 +0000] rev 4257
compat: drop 4.3 compatiblity code for `ui.edit` method
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Nov 2018 01:42:50 +0000] rev 4256
compat: drop 4.3 compatiblity code for 'successors' revset
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Nov 2018 01:41:36 +0000] rev 4255
compat: drop 4.3 compatiblity code for 'precursors' revset
Matt Harbison <matt_harbison@yahoo.com> [Sat, 10 Nov 2018 23:54:46 -0500] rev 4254
compat: drop Mercurial 4.3 support for exthelper
The last release email noted plans to drop 4.3 and 4.4 support in the next
feature release. I'd like to move this code into core, and dropping this should
allow the class to be copied in unmodified.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Nov 2018 01:49:34 +0000] rev 4253
compat: update metadata about minimum ag version
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 06 Nov 2018 10:41:50 +0530] rev 4252
next: solve the issue of `next` get confused by split
This patch solve a problem of next command which get confused by split.
Let me describe how it was getting confused:
Initial state of repo:
A---B---C
After splitting B to (B1,B2):
@
A---B1---B2
\
---B---C
X *
(note: C is orphan; checkedout to B1)
Lets make an amend on B1:
@
B1'
/
A---B1---B2
\ X *
\
---B---C
X *
Now, if run `hg next` (--evolve is True by default now):
$ it would give you choice to choose from B2 and C thinking that C could also
be a possbile children for B1, instead of stablizing B2 on B1.
I fixed this problem by filtering those aspiring children which can be
stablized on one of the aspiring children itself.
Changes made in test-prev-next.t shows the changed expected behaviour.
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 06 Nov 2018 15:10:56 +0530] rev 4251
next: add test which shows that `next` get confused by split
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 31 Oct 2018 14:08:56 +0530] rev 4250
cleanup: avoid a Yoda condition
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 31 Oct 2018 14:06:17 +0530] rev 4249
evolve: modify and move the comment to appropriate position
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 31 Oct 2018 14:01:58 +0530] rev 4248
next: update the command description
Now, if necessary next command evolve the next child revision
by defualt. You don't need to pass the --evolve flag.
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 10 Nov 2018 15:50:05 +0100] rev 4247
next: make next command --evolve by default
Before this patch, if we need to evolve to update to the next child,
we were suggesting the user to use --evolve flag. This patch make some
changes to evolve by default in that conditions.
After making next command to evolve by default we have to consider
the following points:
1) If we don't need to evolve while updating to the next child:
a) And if wdir is dirty, we suggest to use --merge flag
b) if wdir is clean, we simply update to next child (if ambiguous,
prompt the user to select one)
2) If we need to evolve:
a) when wdir is dirty, we suggest the user to use `hg shelve` first,
to make wdir clean. As we don't support --merge while evovling.
b) when wdir is clean, we evolve the next cset.
Changes made in test-prev-next.t reflect the changed behaviour.