exthelper: drop compatibility layer for `command` We dropped support for 4.2.

topic: drop compat layer for `command` We dropped support for 4.2

legacy: drop compat layer for "command"

drophack: drop compat layer for "command"

compat: drop compatibility layer for updatecaches The `repo.updatecaches` method is support since Mercurial 4.2

branching: merge with stable

obshashrange: force saving of stablesort and firstmerge cache For some reason the check in repo is not working for stable sort. We also force firstmerge to be saved as test show it was missing.

test: add a test about cache warming This test reveal that multiple cache are not saved to disk after discovery (firstmerge, stablesort).

stablerange: save stablesort cache alongside the stablerange one This one does not introduce inconsistency but helps performance. G: changed hgext3rd/evolve/stablerangecache.py

obshashrange: always save stable range cache alongside the obshashrange one If the on disk date cover different area, the invalidation of affected range will misbehave.

obshashrange: clear in-memory cache alongside the sqlite one Clearing on disk data in nice, but we also need to remove in memory one or we'll get incorrect results.

branching: merge with fixes on stable

changelog: summarize the recent improvement

obshashrange: re-enabled more selective pruning of affected range

obshashrange: fix computation of affected ranges The computation of impacted nodes and associated revs is fully reworked. In addition,we introduce multiple new tests covering cases that were previous wrongly handled.

obshashrange: add more validation output to tests We are about to update the logic and add more tests.

obshashrange: correctly detect changeset directly affected by prune Before this changesets, parent of standard obsmarkers were wrongly considered affected and pruned changeset were wrongly not considered affected.

obshashrange: do not search for affected ranges above the highest we have It is a fast way to know we don't have an affected range for an affected revision.

obshashrange: do not search for affected stable range cache is unavailable Before this changeset we where resetting in all cases, and then looking for affected ranges. In addition is the stable range were not available, the functions silently returned no ranges affected. Now, do one or the other depending of the availability of the stable range cache. In practice we always do a broad reset because the code detecting affected changeset is currently buggy.

stablerange: build closure a bit less inefficiently The new way make me a bit less sad than the old one.

discovery: make sure repository wrapping happens in the right order Otherwise we may end up in situation were cache are not warmed in the right order, crashing.

branching: merge with stable

changelog: add an entry about the next --evolve fix

changelog: update 8.1.0 release date

next: fix topic constraint in the --evolve case We were using the wrong variable.

next: use set for membership testing There are no reason to use a list here.

test: adapt to core output change on unknown command CORE-TEST-OUTPUT-UPDATE: 5199c5b6fd29

compat: use new style template keyword declaration

test: fix previous changeset output The previous changeset got published prematurely.

obshashrange: add a test for `hg debugupdatecache` It seem to be properly filling the caches.

branching: merge with stable

templatekw: do not override in-core {obsolete} keyword The extension version uses old API, which will be deprecated in Mercurial 4.8.

packaging: mark version as development version This avoid confusion when installing non-tagged version.

Added tag 8.1.0 for changeset 2c5d79c6459c

packaging: prepare version

branching: merge stable into default

test-compat: merge mercurial-4.4 into mercurial-4.3

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge stable into mercurial-4.6

compat: fix obslog compatiblity with 4.3 Due to the way of how successor sets are retrieved in new Mercurial version, retrieving it again in 4.3 way would be a performance hit and complexify the code too much. Don't retrieve markers of successor sets which makes obslog filtered output more limited in 4.3.

compat: add a fixed version of mergecopies for hg<=4.3 In hg<=4.3, copies._fullcopytracing() does not exist and we have to wrap copies.mergecopies() to fix the AssertionError coming from core.

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge stable into mercurial-4.6

compat: make compatible call to ui.edit for hg <= 4.3 This is similar to what is already happening elsewhere.

compat: ignore extra status feature for hg <= 4.3 The feature does not exist in 4.3 and below.

format: fix indentation level Previous change got pushed without the fix by mistake.

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge stable into mercurial-4.6

compat: disable empty topic warning on `hg phases` for hg <=4.5 This is annoying to support for lower version.

compat: restore compatibility with Mercurial <= 4.5 The __init__ arguments changed a lot in 4.6 and 4.7, lets do be as transparent as possible

test-compat: merge stable into mercurial-4.6

test-compat: merge stable into mercurial-4.6

branching: merge stable back into default

compat: improve detection of Mercurial 4.6 fixed case where AttributeError can be thrown when importing wireproto

cleanup: use NotImplementedError instead of NotImplemented Caught by pyflakes.

CHANGELOG: add some entries and remove duplicated entries

branching: merge default into stable The stable branch of Mercurial core now contains Mercurial 4.7 so evolve branch policy requires this merge. The @ bookmark is in the right location, so people doing clone will get to the latest release.

branching: merge with the other head

test-compat: backed out changeset 8fe8152ff071 These output change were for 4.7 only.

test-compat: backed out changeset 41fc764bf28c These output change are for mercurial-4.7 only

test-compat: backed out changeset dda5b2134b32 These change were for Mercurial 4.7 only.

test-compat: backout change to 1e103c7f7663

compat: use older API for older version This API changed in 4.7, we need to adjust.

branching: create mercurial-4.6 branch for updated test output This branch will be used to check for 4.6 compatibility.

builddependencies: extract function for getting successors The code no longer makes a difference between single- and mult-successor cases and just needs a set (or generator, really) of successors to iterate over. Let's extract that into a function.

builddependencies: share code between single- and multi-successor cases The two cases now have more similar structure ("if succ in revs: dependencies[r].add(succ)"), so let's share the code so it doesn't start drifting apart again.

builddependencies: build inverse dict from forward dict It's error-prone to keep "dependencies" and "rdependencies" in sync (we don't do it correctly when there are multiple successors or a node). It's easier to just create "rependencies" from "dependencies" after it's complete.

builddependencies: remove a use of defaultdict I don't see much reason to make "rdependencies" be a defaultdict when "dependencies" is not. It's easy to initialize each entry ourselves.

branching: merge with stable

builddependencies: don't remove found deps when divergence found (issue5946) It seems obviously wrong to not keep any dependencies for a revision that we had already found (for p1) if we run into divergence (from p2). It also happens to fix issue5946 :)

builddependencies: don't add dependency on revision outside input set This was already handled in the single-successor case, but had been missed in the multiple-successors case. Note that there seems to be a copy of builddependencies() in the topics extension. I don't use topics more than I have to, so I'll let someone else fix that code.

builddependencies: consider all divergent successors We were only considering one. In test-evolve-abort-conentdiv.t:165, the input revs were {5, 8} and dependency dict was {8: set([]), 5: set([10])}, which is a little weird (10 is not in the input set). It still worked because the callers used it (they seemed to only care if there were *any* dependencies). This patch fixes the issue by considering all successors. That means the dependency dict will be {8: set([]), 5: set([8, 10])} after this patch. The next patch will remove the 10 from that set.

tests: add test for issue5946 The test case is a copy of the one for 5833. The only difference is that the merge parents are recorded in the opposite order (and that the test is truncated because it fails).

obslog: check filtered output with folded changesets

obslog: check filtered output with splitted changesets

obslog: check filtered output with pruned changesets

obslog: check filtered output with amended changesets

tests: add a content-divergent obshistory test

tests: extract the obshistory amend then fold test case into a separate file

tests: extract the content-divergence test case into a separate file

tests: extract the obshistory fold test case into a separate file

tests: extract the obshistory lots of split test case into a separate file

tests: extract the obshistory split test case into a separate file

tests: extract the obshistory prune test case into a separate file

tests: extract the obshistory amend test case into a separate file

tests: extract obshistory setup in a separate file We are gonna soon explode the obshistory test file into several, extract the setup to reuse it as much as possible.

obslog: add a new flag to filter out non-local nodes

compat: drop compatibility hack for mercurial <4.3 We no longer support version prior 4.3.

compat: temporarily move copies fix to compat.py This patch moves a fixed version of copies._fullcopytracing() to compat.py as this was not fixed in core before release and also we need to do this anyway for the older versions of mercurial. This fix is that when base changeset is not ancestor of any of the merging commits, we don't throw an error. The phabricator differential which will fix this in core is https://phab.mercurial-scm.org/D3896. This fixes the traceback we get in previous changeset while relocating one of the content-divergent changeset.

evolve: continue conflicted relocation content-divergence This patch adds logic to continue an conflicted content-divergence resolution which was interrupted while relocating one of the divergent commits. The tests shows the there is some mishandling of copies internally which will be fixed in next patch.

topic: use self instead of repo in topicrepo methods Referring to repo here was somehow preventing it from being garbage-collected (important in hgweb, where currently every request gets a new repo).

evolvecmd: introduce fn to be wrapped by extensions resolving content-div The function added will be used by extension by wrapping it and adding logic to merge data introduced by them. For example: topic extension can wrap this function and add logic to merge topic names.

evolvecmd: move remaining logic to merge commit desc to existing utility fn This was a bit awful because we had a utility function and still we did some of merging outside of that fn. So let's move the remaining parts there.

amend: allow aborting an `amend --patch` by saving an empty file (issue5925) This patch fixes issue5925 by allow aborting a `hg amend --patch` call by saving an empty patch file. This is similar to aborting of `hg amend` when commit message is empty. Test changes demonstrate the fix.

tests: add a test to demonstrate issue5925 The issue will be fixed in next patch.

test: fix possible output change from 4.7 Change in debug timing can display these extra messages.

state: add the get() method that evolvecmd:1836 expects

rewing: prevent rewind in case of uncommitted changes rewind can update, which means merge and troubles. We might relax this limitation in the future.

rewind: default to rewinding the current stack

rewing: add the ability to rewind "from" revisions

evolve: exclude "identical" precursors from the precursors set I'm not sure it is the right thing to do, but it simply thing a lot for now. Otherwise, using 'precursors' to find rewind direction become too complex. This is going to give problematic result in case of prune. Since there are no other precursors to follow.

rewind: move revision selection into its own function This will help making the logic more advanced.

rewind: automatically rewind entire stack We now rewind the full stack, avoiding creating orphans. A `--exact` flag is added to force rewinding only the explicitly specified changesets.

rewind: add a test about rewinding top of stack For now this rewind is creating an orphan. We add the test to check the behavior in that case.

rewind: use rewinded parent when creating multiple changesets Use use the rewinded parent instead of creating orphans based on identical, but obsolete, changesets.

rewind: add a test for rewinding a fold The code already have basic support for case. However the result create orphan that will need to be improved. However, we keep this changeset simple.

rewind: add a test for rewinding a split There are no code change needed but it is worth testing on its own.

rewind: update the working copy if it gets obsoleted If the working copy parent is rewinded, follow the rewind.

rewind: add a message about obsolete changeset Not the best output, but useful to have the data. We can improve that later.

rewind: obsolete latest successors unless instructed otherwise To prevent the creations of divergence, we automatically mark the successors set of the rewinded changeset as obsoleted by the rewind result. A new flag `--as-divergence` is added to disable this behavior.

rewind: test rewinding an amended changesets We are now able to rewind a simple amended changeset. For now, its current successors has not been obsoleted and we created divergence.

rewind: add a message about the rewinded changesets This helps to understand what happened.

rewind: add a proto version of the command This first version focus on rewinding a single revision without care for the consequence.

stablesort: make sure heads are processed in sorted order changeset 72621094505f will fix some ordering issue in the `heads` revset so we stabilise the output in advance.

evolve: move the bookmarks also when updating to successor (issue5923) When we are on an obsolete node and does `hg evolve`, it updates to it's sucessor, however it does not move the bookmark to the successor. This patch adds logic to make sure we move the bookmark too. Test change demonstrates the fix.

tests: add test to demonstrate issue5923 This will be fixed in upcoming patch.

changelog: add an entry about the new `evolve.interrupted` section

evolve: make one missed error to align other error messages Previous patches missed this error to change it to the new format. Let's align this with all other messages raised by `hg evolve` command.

evolve: raise error.InterventionRequired instead of Abort when conflicts error.InterventionRequired is a better error to raise in such cases. Thanks to marmoute for noticing this.

changelog: add a changelog entry about divergence resolution We made a lots of progress there.

evolve: create resolved cset on successors of current parents While resolving content-divergence, sometimes, the parent can be obsolete and have a successor. We should consider the successors of the parents instead of obsolete parents as that will do something like orphan+content-divergence resolution both at the same time which is powerful and results in a single stack while resolving content-divergence of stacks. The test changes demonstrates that we can now successfully evolve a content divergent stack.

tests: fix a test case to not create conflicts This is the test case where we are testing about divergence resolution of stack of patches. If the stack is as follows: C1 C2 | | B1 B2 | | A1 A2 \/ base And A1-A2, B1-B2 and C1-C2 are content-divergent, and merging A1-A2 results in conflicts. Now if you resolve conflicts and continue resoling B1-B2, the conflicts of A1-A2 will still be there. We need somehow to understand the work we has done and not create conflicts again. To test the evolution functionality for now, we make sure conflicts does not occur.

evolve: introduce a resolutionparent variable and store it in evolvestate This patch introduces a resolutionparent variable which will be the parent of final changeset after resolving content-divergent changesets. Till now, the parent is always the parent of one of the divergent node, but now in upcoming cases, it can be a successor of both the parents of divergent nodes.

evolve: introduce a dirstatedance() fn to fix dirstate after parent change This patch introduces a dirstatedance() function which will be used after fixing the dirstate when we change parents using repo.dirstate.setparents(). Look at docs added for more details.

evolve: create a new commit instead of amending one of the divergents This patch changes the behavior of evolve command while resolving content-divergence to create a new commit instead of amending one of the divergent ones. In past, I have made this change, backed out this change and now today again I am doing this change, so let's dive in some history. Using cmdrewrite.amend() was never a good option as that requires hack to delete the evolvestate and also gives us less control over things. We can't make the commit on top of different parents as that of content-divergent ones. Due to all these, I first made this change to create a new commit instead of amending one. But, after few days, there was flakiness observed in the tests and turned out that we need to do some dirstate dance as repo.dirstate.setparents() does not always fix the dirstate. That flakiness was a blocker for progress at that time and we decided to switch to amend back so that we can have things working with some hacks and we can later fix the implementation part. Now, yesterday while tackling resolving content-divergence of a stack which is as follows: C1 C2 | | B1 B2 | | A1 A2 \/ base where, A1-A2, B1-B2, C1-C2 are content-divergent with each other. Now we can resolve A1-A2 very well because they have the same parent and let's say that resolution leads to A3. Now, we want to resolve B1-B2 and make the new resolution commit on top of A3 so that we can end up something like: C3 | B3 | A3 | base however, amending one of the divergent changesets, it's not possible to create a commit on a different parent like A3 here without some relocation. We should prevent relocation as that may leads to some conflicts and should change the parent before committing. So, looking ahead, we can't move with using amend as still using that we will need some relocation hacks making code ugly and prone to bad behaviors, bugs. Let's change back to creating a new commit so that we can move forward in a good way. About repo.dirstate.setparents() not setting the dirstate, I have researched yesterday night about how we can do that and found out that we can use cmdrewrite._uncommitdirstate() here. Expect upcoming patches to improve the documentation of that function. There are lot of test changes because of change in hash but there is no behavior change. The only behavior change is in test-evolve-abort-contentdiv.t which is nice because creating a new commit helps us in stripping that while aborting. We have a lot of testing of content-divergence and no behavior change gives enough confidence for making this change. I reviewed the patch carefully to make sure there is no behavior change and I suggest reviewer to do the same.

evolve: always order the revs to be evolved The current code only order the revs if we are resolving orphans and not in other case. The ordering is important when we pass --all and tackle multiple occurence of the same instability. Let's order the revs for each instability. There are enough test coverage of phase-divergence and content-divergence that I feel confident doing it because none of the test changed. The change in test-evolve-content-divergent.t demonstrates the indeed ordering helped.

tests: add test of resolution of content-divergent stacks This patch adds a test of resolution of content-divergence stacks where a series of changesets get mutated as two different series resulting in whole content-divergent stacks. As the tests shows, we are not processing the changesets in right order which needs to be fixed first.

evolve: improve error messages when conflicts occur This patch improves the error messages when conflicts occur. First, we drop the line 'evolution failed', that is not the best line we can show and evolution didn't failed, it's just interrupted by the conflicts and when user will run `hg evolve --continue`, things will be fine. I still remember when I first saw 'evolution failed', I got a bit scare as am I in a recoverable position or not. So let's drop this scary line. Second, we replace the error messages to say `resolve conflicts and see help-topic`. The help topic was added recently and documents all the three flags very well. Addition of tests also showed that all the three flags works fine with all the three instability type. So we should advertise them more. Third, we now raise the error with our error message rather than raising MergeFailure and having evolution related text in hint or stderr above. This increase the focus on the error message we want to show. After this patch, I think error messages by evolve in case of conflicts will be same in every case.

evolve: point to `hg help evolve.interrupted` while resolving content-div Recent test additions shows that --abort and --stop works well while resolving content-divergence and we should advertise them. This patch does so by pointing to evolve.interrupted help topic.

tests: add test about aborting content-divergence when multiple parents This patch adds tests for --abort flag of hg evolve command when we are resolving content-divergence which are on different parents and parent of one of them is the gca of both of them. The tests shows that we are doing good and we should advertise the flag during conflicts.

CHANGELOG: add an entry about the --update flag Since --update is still the default, we make the entry about --no-update.

evolve: show unfinished information in `hg status -v` (issue5886) `hg status -v` shows information about unfinished states or `hg status` shows it when `commands.status.verbose=True` is set. Before this patch, information about interrupted evolve does not show up because evolve does not resgiters in cmdutil.STATES. This patch make sure we register evolve related information there. There has been an idea to unify cmdutil.unfinishedstates and cmdutil.STATES which needs some work and the resulting state does looks a bit complicated. So till the time we unify them, let's fix this bug by registering in cmdutil.STATES.

style: drop a (commented) debug print Left-over from 4dcf87849f9d.

tests: update tests output with changes in d0abd7949ea3 in core hg CORE-TEST-OUTPUT-UPDATE: d0abd7949ea3 CORE-TEST-OUTPUT-UPDATE: 1e9c357d3ddf

branching: merge with stable Merging with the new 8.0.1 release.

Added tag 8.0.1 for changeset 0887c30255a1

packaging: prepare for 8.0.1 release

changelog: add a couple of missing entry

evolve: strip the extra obsmarkers if any on `hg evolve --abort` Previous patches started storing some obsmarkers which needs to stripped during `evolve --abort` which can't be stripped by stripping the new evolved changesets because they point to a node which existed before the evolution was performed. This patch adds logic to strip those obsmarkers by finding their indices in the obsstore and then stripping them.

evolve: store the obsmarkers to be deleted in evolvestate Sometimes, we don't create a new node and obsolete one of the old node in favour of an existing node. When user calls, `hg evolve --abort`, we need to strip that obsmarker to go back in the same old state. The obsmarker created for new node are stripped when the new nodes are stripped. This patch start storing such obsmarkers in the evolvestate so that we can delete them later if required. Right now we just store successsor and predecessor information, we might need a better obsmarker serialization techinque in future to make it more robust.

evolve: store obsmarkers to be deleted in evolvestate There are operations which don't create a new node rather they just obsolete one of the unstable node in favour of existing one. In such cases if a further resolution leads to conflicts and user calls `evolve --abort` or `evolve --stop`, we might need to delete that obsmarker. So let's store such obsmarkers in the evolvestate.

evolve: factor out logic to merge branches in separate function This patch moves the logic to merge branches while resolving content-divergence to a separate function. This makes code clear and better to understand.

tests: add more test of --stop while resolving content-divergence This tests the --stop flag when conflicts occur while relocating one of the divergent changesets.

evolve: strip the relocation commit on `hg evolve --stop` While resolving content-divergence on multiple parents, we relocate one of the commit on the parent of another one and then merge the divergent changesets. Merging can leads to conflicts, and if user does `hg evolve --stop`, we need to strip that relocated changeset too! This patch does that. Test changes demonstrates the fix.

evolve: declare updated and pctx variables in stopevolve() They will used in next patch.

evolve: store the old other divergent node after relocation in evolvestate When the content-divergent changes are on different parents and we relocate of the node to the parent of another one, we get a new other-divergent node. We still need to store the older other-divergent in evolvestate so that we can use that information.

evolve: factor out logic for --stop flag in separate function This will make code clean

tests: add test for --stop flag when resolving multiparents content-div This patch adds a test for --stop flag when we are in an interrupted content-divergent resolution which have multiple parents. Conflicts happen we merge the divergent changesets after relocation. The test shows that we need to strip the relocated changeset.

evolve: move logic to continue interrupted content-div resolution to new fn Each of the other type has defined their own function to continue/complete the interrupted resolution. We take out the logic for content-div resolution too in a separate function to make the top level function looks clean.

evolve: rename help topic evolve.interrupted-evolve to evolve.interrupted `evolve.interrupted-evolve` has the word evolve twice. Now that this help topic is a part of evolve command, evolve.interrupted will mean the interrupted evolve command only.

packaging: update tested-with statements in evolve and topic

CHANGELOG: mention about 4.6.1 compatibility

test-compat: merge mercurial-4.4 into mercurial-4.3

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge stable into mercurial-4.5

utility: use ui.interactive() instead of checking config value Before this patch, the rev selection prompt which pops up in case of ambiguity to ask user to select a rev used to check the config value of ui.interactive which can is by default set to None. We should use ui.interactive() instead which is more smart in such cases. Thanks to martinvonz for suggesting this.

CHANGELOG: add couple of entries about things fixed We are preparing for a release!

next-prev: always respect the --merge flag An earlier bug fix series which started respecting commands.update.check introduced a bug in which --merge was not respected sometimes. This patch fixes that behavior by passing updatecheck as 'none' to hg.updatetotally() if --merge is passed which is similar to what `hg update` does.

next-prev: add tests showing --merge not respected in some cases This patch adds tests which show that --merge is not respected when you set commands.update.check to any value. This is a bug I wrote few days ago and will fix it in next changeset. I like this process of writing bugs and fixing them.

evolve: store the evolvestate if relocation results in conflicts We missed storing the evolvestate on disk when relocation lead to conflicts. We need to store it to grab information to continue or abort or stop the evolve.

tests: add more test of resolution of content-divergent changesets This patch adds test of resolution of content-divergent changesets when relocation is required and it leads to conflicts. The test shows that we are not doing the right thing. This will be fixed in upcoming patches.

evolvestate: store info about relocation while resolving content-divergence While resolving content-divergence when they are on different parents, we relocate one of the node to parent of another one and this can lead to conflicts sometimes. So we need to store information about that state in evolvestate so that we can use that when user does `hg evolve --continue` or `--stop` or `--abort`. Now that we make sure, we store the new other node in evolvestate, we fix the behavior of handling the relocated commit and merge the right changesets.

evolve: factor out logic to merge content divergent csets in separate fn This will help us in reusing the logic if we need to while doing evolve --continue.

evolve: commit the transaction if conflicts occur while merging content-div Yes, let's commit the transaction in case conflicts occur. Yes, this is what unshelve does and this is one of the reasons we don't like unshelve. Previous patches added support for resolving content-divergence when they are on different parents with parent of one being the gca. In such cases, we relocate one of the divergent commit to the parent of another one. All the relocation stuff and merging divergent changeset stuff happens in a single transaction, so if there are conflicts while merging, we abort and the transaction rollsback and our relocated commit is not applied after abort. We don't want to process the relocation because that can lead to conflicts and we will have dirty wdir because of resolving conflicts. So, we commit the transaction when merging results in conflicts to make sure if relocation happened, we commit that. This fixes the absence of relocation commit found in previous patch and uncover a new bug about handling of relocated commit. Upcoming patch will fix it.

tests: add tests for resolving content-divergence when different parents This patch adds more tests for cases when we try to resolve content-divergence when they are on different parents. The last test shows the we are somehow missing the relocated commit in interrupted transaction. This will be fixed in next patch.

evolve: implement resolution of content-divergence when on differet parents This patch implements the basic version of resolution of content-divergence changesets when they are on different parents but one of the parent is gca of both the different parents. The functionality first relocates the divergent changeset which was left behind and then resolves the content-divergence like it resolves in normal cases. This is a very basic implementation because it still does not work on interrupted evolution. Test changes in this patch shows the basic functionality working. The output of dry-run is also required to be tweaked in such cased. Upcoming patches will add more tests and will improve the implementation to work during conflicts too.

tests: add tests for resolving content-divergence with parent change This patch adds a new test file test-evolve-content-divergence.t which tests the resolution of content divergence when the divergent changesets does not have the same parents.

CHANGELOG: add an entry about fixing issue5877

evolve: pop up editor if conflicts occur while merging commit messages Last patch added support for merging commit messages while resolving content divergence. In case of conflicts we fallback to one of the divergent commit messages. After this patch, we will pop up an editor where user has to resolve the conflicts in the commit messages and then continue. Tests are added for this. We need to fix handling in test-sharing.t to use HGEDITOR to fix conflicts and pass the new commit message. Future improvement can be that we should respect HGMERGE while merging commit descriptions too.

evolve: merge commit messages while resolving content-divergence (issue5877) While resolving content-divergence, there can be divergence in commit messages too which should be resolved. This patch uses the hg's internal merge API's to merge commit messages of divergent changesets with predecessor as the base. In case of conflicts, we fallback to divergent's commit message which should be changed in future. We should pop up the editor with the commit message and the conflict markers and let user fix that. Tests are added for the functionality added.

evolve: move if-else block under the right block the index related if-else should be only executed when all three base, divergent and other have different branch names. I coded this last night and mistakenly mis-indented it. Caught when I was adding more tests.

tests: make sure we don't result in commit messages conflict Upcoming patches will introduce functionality of merging commit messages while resolving content divergence which can lead to conflicts. We don't want to test the conflicts scenario here, so let's make sure there are no conflicts of commit messages in this test.

tests: don't use mkcommit shell function in test-divergent.t Upcoming series will start merging commit descriptions while resolving content-divergence. This tests are here to test the basics of content-divegrence resolution and we should not be testing much of commit description merge here. Replacing mkcommit function with normal hg calls will help us decide on the commit messages ourselves and prevent conflicts while merging commit messages.

evolve: remove duplicated documentation File saving failure…

evolve: show `hg help evolve.interrupted-evolve` in error when conflicts The help list various flags which you can use during interrupted evolve resolution and description about what they do. This will be very helpful for user on how to continue an interrupted evolve.

evolve: add a help topic `Interrupted-Evolve` This help topic contains description on how the various flags work during interrupted evolve. This help topic will be included in error message during interrupted evolve in next patch.

branching: merge with stable

changelog: fix version number error

evolve: return the new node formed only as the replacement sometimes, the the other content divergent changeset is obsoleted in favour of the local divergent changeset in which case we should not store that as a replacement because `hg evolve --abort` will strip that changeset. Let's make sure we return the newnode only if formed. The test results shows that we are still not 100% accurate as we need to strip an obsmarker.

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.

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.

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.

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.

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.

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

CHANGELOG: add an entry about issue 5808 being fixed

next-prev: replace the error hint to mention about `--merge` flag

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.

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.

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.

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`.

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.

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.

CHANGELOG: add an entry about fixing issue5897

evolve: fix `hg abort` when hg next --evolve leads to conflicts (issue5897) Before this patch, if you do `hg next --evolve` and end up having conflicts and then you try `hg abort`, it will throw a KeyError. This patch fixes that.

tests: add a test demonstrating issue5897 When conflicts are caused due to `hg next --evolve`, `hg evolve --abort` breaks! This patch adds test to demonstrate that. This will be fixed in next patch.

evolve: add an `--update` flag to `hg evolve` command This patch adds a new `--update` flag which defaults to True. The update flag updates the working directory to the head of evolved revisions after `hg evolve` command. This flag can be used to not update your working directory after `hg evolve` which has been one of the biggest feature request from fig team at Google. To not update your working directory, the user can do `hg evolve --no-update`. If the working directory get obsoleted by evolve command, it will update to the successor. This patch also adds some basic tests for the flag introduced.

tests: add tests for testing --abort while content-divergence resolution This patch adds a new test file with a very basic test of `--abort` on an interrupted evolve which was resolving content-divergence. Upcoming patches will add more rigourous tests.

evolve: fix storage of replacements and temprevs node in evolvestate The _completephaseivergent() was not respecting rules on how to store the new node ids created in evolvestate. The rules are: * store the temporary relocated commits in temprevs * store the final new commit in replacements This patch make sure we follow the above rules and also use the return value returned by _resolvephasedivergence(). The tests change demonstrates that we are all good now.

tests: add more tests related to aborting while resolving phase-divergence The tests shows the something is still broken related to abort while resolving phase-divergence which will be fixed in upcoming patches.

topic: suggest to clear a topic that becomes empty We add a hint suggesting "hg topic --clear" when a topic becomes empty. This usually happens when all its changesets get public, that is when the user does a 'phase -p' or when they pull from a server. To discriminate relevant cases for which we should display the hint (and typically exclude explicit 'hg topic --clear' operation), we look for the transaction "type" to only consider 'phase' or 'push' transaction. In the latter case, the transaction name is not simply 'push-response' but it also included the remote URL so we need to match on string content.

topic: display a hint pointing at help when a topic becomes non-empty This is an attempt at avoiding "mistakes" by new users of topics when they pull a topic and publish its changesets while being checked out. In this case, the topic will become empty but still be active; however, if this is a "foreign" topic, the user will not likely want to keep it active for the next commit operation. So we add a hint message pointing at general help of "topics" command so that they can eventually do something and learn about "hg topics --clear".

branching: merge with compat fix on default

evolve: add compat for repair.stripbmrevset which is moved to scmutil This patch adds compatibility logic for repair.stripbmrevset() which is moved to scmutil as bookmarkrevs(). This fixes test-prune.t failure.

evolve: update the readme with more information about contribution

topic: dedent items about publishing behavior in docstring Also change item bullets from '#' to '*'.

topic: use preformatted block for config snippets documentation We add :: markers, empty line and properly indent blocks where needed.

tests: add a test for "hg help -e topic" Currently, some configuration snippets do not render well; we'll fix this in forthcoming changesets.

branching: merge with stable

content-div: add test showing `--stop` works during interrupted resolution This patch adds a test showing that the --stop flag of `hg evolve` works well during interrupted content-divergence resolution. The --stop flag now works with all the three different type of instability resolution very well and we should advertise it more.

evolve: create new commit while resolving content-divergence Before this patch, we used to amend one of the content-divergent changes with the changes from the merge. Creating a new commit will certain advantages like letting user enter a commit message, showing user the new merge diff before commiting the content-divergent resolution and give us more control in the implementation part. The reason amend was used initially was just because it was easy. There are some tests update due to change.

content-divergence: store the resolved revs in evolvestate['replacements'] The support for continuing a conflicted content-divergence resolution was added some time ago. That support lacked storing of the resolved rev in the evolvestate['replacements'] which marks the node as resolved and does not try to resolve that node again. Since we didn't store, the resolution, processes the same node again. This patch makes sure we store the information in evolvestate that a certain content-divergent node is resolved to prevent pre-processing it again.

utility: use ui.interactive() instead of checking config value Before this patch, the rev selection prompt which pops up in case of ambiguity to ask user to select a rev used to check the config value of ui.interactive which can is by default set to None. We should use ui.interactive() instead which is more smart in such cases. Thanks to martinvonz for suggesting this.

evolve: make `--abort` strip the temporary revs created during resolution During divergence resolution, `hg evolve` created temporary relocation commits which needs to be stripped off during `hg evolve --abort` to get back to the same state where we were. Previous patch added a new list temprevs to be stored in evolvestate. This patch starts storing the temp relocated node created during phase-divergence resolution in evolvestate and make sure we consider stripping it too while `hg evolve --abort`. The test changes demonstrate the fix. Now we are sucessfully aborting a phase-divergence resolution.

evolve: store a list of temprevs in evolvestate There are temporary revisions which are created as a part of divergence resolution which needs to be stripped off if user runs `hg evolve --abort`. We need to save the nodeids of those temporary revisions in the evolvestate. The temprevs list will help in the above mentioned use cases.

evolve: check for None before adding in set of revisions to strip After previous patch, replacements can contain None. Let's make sure we don't add None to the revisions to strip during `hg evolve --abort` The test changes demonstrate the usefulness of this and the previous patch. Now abort is working and public changesets are not a problem.

evolve: return the new replacement node to be stored in evolvestate While resolving phase-divergence, we can end up obsoleting the phase-divergent commit in favor of the public commit. Before this patch we return the node of public commit to store as a replacement of the phase-divergent commit. The above will not cause any problem till the time we use `hg evolve --abort` on an interrupted evolve which tries to strip the replacement nodes because it thinks that the replacements nodes are the ones which are created during the resolution and are new. Since we will be stripping a public node, `evolve --abort` will error out saying cannot strip public changeset, unable to abort evolve which is bad. We should make sure, replacements should only consist of new nodes formed. If the instablity is resolved by obsoleting in favour of old changeset, we should not store the old changeset in replacements in evolvestate.

evolve: don't make values of replacements dict lists There was inconsistency in code base related to the values stored in replacements dict in evolvestate. At some places we store a list, at some places we just store the nodeid. Let's make sure we store only the nodeid, not a list. If there are cases, when there are multiple replacements or changesets created during resolution, later patch will introduce storing temprevs in evolvestate which should be used.

tests: add a test file `--abort` flag while resolving phase-divergence This patch adds a new test file test-evolve-abort-phasediv.t which will contain tests for `hg evolve --abort` flag while resolving phase-divergence. There is a case in this test which does not work right which will be fixed in upcoming patches.

evolve: pass revisions as strings to commands.*() It's usually fine to pass integer revisions to e.g. commands.update(), but when directaccess is enabled, it attempts to parse it a revset, which fails.

tests: rename test-evolve-abort.t to test-evolve-abort-orphan.t We renamed the test file because it contains all the cases related to orphan resolution. Now we care about divergence resolution too and hence we must have separate specific test files for each type.

branching: merge with branch for stable

compat: update obshashrange test output Mercurial core bfe8ef6e370e seems to have changed the order of some messages. Simply accept the change in the test file. CORE-TEST-OUTPUT-UPDATE: bfe8ef6e370e

test: update to new outputs Mercurial core ea63a2004d09 update the hidden changeset warning during update after the effective update. CORE-TEST-OUTPUT-UPDATE: ea63a2004d09

compat: fix obslog with Mercurial 4.6+ Mercurial core 3fe1c9263024 removed the diffopts attribute on changesetprinter. Backport consuming diffopts in the constructor for old versions of changesetprinter and update the non-graph code to extract the patch option and pass it directly.

debian: add line to clean-docs target to delete additional docs file

amend: use context manager for locks (issue5887)

evolve: point to '--abort' in verbose status message f6979d64b9fb (evolve: point to '--abort' in error message, 2018-04-22) changed "hg update -C ." to "hg evolve --abort" in error messages. This commit makes the same change in the verbose status message (the one that warns about unfinished evolve). There's still one mention "hg update -C" in our codebase. That's after "hg evolve --content-divergent" fails, but I don't think "hg evolve --abort" works in that case (yet?).

evolvecmd: add comments and new lines in content-divergence handling logic I have visited this logic three times in last 10 days and I have to re-read the whole code to make sure I don't miss any part. Adding comments will help understanding the code in better and fast way.

evolve: show cset hash in "merging conetnt-divergent changeset" While I was here I also mae de it repo.ui.status() instead of repo.ui.note() to align the behavior with rest of the messages.

evolve: show cset hash in "update to local conflict" message

evolve: use hg.updaterepo() instead of hg.update() to hide stats

evolve: fix the conflicts error message during content-divergence resolution Before last patch, we didn't had an automated way to continue an interrupted content-divergence resolution and we used to show a very long error message on how to continue manually. This patch replaces that long error message with nice small message which tells how to continue and how to abort. We still show `hg update -C .` to abort as we need to test and make `--abort` work in case of content-divergence.

evolve: add logic to continue interrupted content-divergence resolution We continue the interrupted content-divergence using the logic to complete content-divergence which we refactored in it's own function few patches ago. We had to delete evolvestate file before using cmdutil.amend() because otherwise we can't use the function. This leads to a hack which deletes the evolvestate file, we may want to not to use the high level API function here. Also we had to pass evolvestate also to _completecontentdivergent function because of this. This patch also, adds a test which demonstrates that the logic works fine.

evolve: store the evolvestate file when encountering conflicts This patch makes `hg evolve` store the evolvestate file when it encounters merge conflicts while resolving content-divergence.

evolve: take out logic to complete phase-divergence in separate fn This patch takes out the logic to complete the content-divergence resolution to it's own separate function so that we can reuse it in case of interrupted resolution.

evolve: store divergent nodes in evolvestate when resolving content-divergence We need to store the divergent nodes in evolvestate so that we can continue an interrupted phase divergence resolution.

branching: merge stable into default