Pulkit Goyal <7895pulkit@gmail.com> [Thu, 24 May 2018 17:04:20 +0530] rev 3791
tests: add more test of --abort flag for content-divergence resolution
This patch adds test when we resolve multiple content-divergence changesets at
once and resolution fo first content-divergence does not form new commits,
resolution of second one leads to conflicts.
As the output shows, we are wrongly stripping a changeset here, which should be
fixed in next patch.
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 04 Jun 2018 04:03:02 +0530] rev 3790
evolve: prompt user for branch selection while resolving content-divergence
When resolving content-divergence, there can be case when both the
content-divergent changesets are on different named branches. In that case, we
are not sure which branch should the resolution commit should be on.
This patch adds logic to prompt user to choose the branch which the resolution
commit should be on and then creates the new resolution commit on that branch.
This also adds a new test file which have tests for the branch selection feature
we have added.
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 05 Jun 2018 03:51:01 +0530] rev 3789
evolve: pass the base revision in _completecontentdivergent()
We need the base revision to merge commit messages, branches and more stuff.
Let's make sure we have that by passing into the function which completes the
divergence resolution.
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 05 Jun 2018 03:49:49 +0530] rev 3788
evolve: store the base of content-divergents in evolvestate
We need the base changeset for merging commit messages, branches. Let's store it
in evolvestate.
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 05 Jun 2018 00:53:21 +0530] rev 3787
evolve: use cmdrewrite.amend() instead of creating a new commit
This patch backs out changeset 88601e1cd5d8.
We replaced cmdrewrite.amend() with creating new commit because using amend(), a
high level function was not good and creating a new commit gave us more control
over things.
**HOWEVER** to get more control, you need to get arrange all the pieces together
perfectly. Creating a new commit, the existing logic has some bugs around
dirstate handling, the `repo.dirstate.setparents()` call especially. Sometimes
this fixes the dirstate correctly sometimes not.
As Pierre-Yves David said, "Having a "clumsy" implementation with the right
behavior is usually a good first step. So having an amend based implementation
seems like a good first step.", let's take a step back and get back using amend
so that we can have a correct basic implementation which is bug free.
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 01:59:41 +0530] rev 3786
corecompat: update the tests output to show phase update summary
eb9835014d20 in core added support to transactions to show a summary on the
phase changed during that transaction. Due to this, couple of tests output needs
to be updated. This patch does that.
While realeasing evolve, this patch should be backed out on branches where
hg<=4.6.
CORE-TEST-OUTPUT-UPDATE: eb9835014d20
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 03:24:43 +0530] rev 3785
CHANGELOG: add an entry about issue 5808 being fixed
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 03:21:25 +0530] rev 3784
next-prev: replace the error hint to mention about `--merge` flag
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 03:13:47 +0530] rev 3783
tests: add tests for conflicts while respecting commands.update.check
This patch adds tests to check that we don't run into conflicts while respecting
commands.update.check.
The error message now does not show the hint about --merge option which we
should fix.
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 02:37:13 +0530] rev 3782
next: respect `commands.update.check` config option in `hg next` (issue5808)
`commands.update.check` config option determines what level of checking should
be done when we update to another revision. When we set this config option to
`noconflict`, it updates your working directory to a specified revision only
when there will be no conflicts which is a very nice behavior.
This patch adds logic to respect the config option so that we can have that nice
behavior with `hg next` too.
It turns out, we just needed to use hg.updatetotally() and add some cases to
check config option.
Right now, we only respect the config if value is set to `noconflict`. Otherwise
we fallback to the default behavior.
This is a part of fixing issue5808. Test changes demonstrate the fix.
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 02:36:24 +0530] rev 3781
prev: respect `commands.update.check` config option in `hg prev` (issue5808)
`commands.update.check` config option determines what level of checking should
be done when we update to another revision. When we set this config option to
`noconflict`, it updates your working directory to a specified revision only
when there will be no conflicts which is a very nice behavior.
This patch adds logic to respect the config option so that we can have that nice
behavior with `hg prev` too.
It turns out, we just needed to use hg.updatetotally() and add some cases to
check config option.
Right now, we only respect the config if value is set to `noconflict`. Otherwise
we fallback to the default behavior.
This is a part of fixing issue5808. Test changes demonstrate the fix.
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 02:50:55 +0530] rev 3780
tests: add test demonstrating issue5808
This patch adds test showing that `next` and `prev` does not respect the
`commands.update.check` config option, particularly when set to `noconflict`.
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 02:26:19 +0530] rev 3779
next: bail out early in `hg next --evolve` if dirty wdir
This patch adds logic to bail out early when --evolve is passed with next
command and the working directory is dirty.
This will help us in preventing the message saying `do you want --merge` which
is useless and misleading when `--evolve` is passed.
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 03 Jun 2018 02:24:28 +0530] rev 3778
tests: add test of `hg next --evolve` with dirty working directory
I was testing some output change to `hg next --evolve` in dirty working
directory and found that we don't have any test for that.