obshistory: implement predecessorsandmarkers() for obsorigin

fold: proposal for output improvement Listing other changeset we got folded with seems like a good idea. We need to think about the case where changesets we got folded with is filtered.

obslog: add display of precursor information to the default template This will still only be output when the user passes --precursors to the command (otherwise the data just won't be there). This addresses a common user request, where they actually would find more intuitive to use --precursors --no-successors.

obslog: add flags to control the output of precursors and successors With just this change, precursors are only shown in structured output.

obslog: extract display of a markers to its own function

tests: allow an empty merge commit to have tests pass without too many changes Not the greatest fix, but this allows us to have the same test case for all versions of Mercurial. Hash of 29 changes because instead of both parents only one is set in hg 5.3.

uncommit: use repo.setparents() instead of repo.dirstate.setparents() setparents() was added to localrepository class in 2012, and now we finally have some differences between calling repo.setparents() vs repo.dirstate.setparents(): _quick_access_* things, introduced in hg 5.3. This patch fixes potential quick-access desync problems where repo[b'.'] would be different from repo.dirstate.p1().

touch: use repo.setparents() instead of repo.dirstate.setparents() setparents() was added to localrepository class in 2012, and now we finally have some differences between calling repo.setparents() vs repo.dirstate.setparents(): _quick_access_* things, introduced in hg 5.3. This patch fixes potential quick-access desync problems where repo[b'.'] would be different from repo.dirstate.p1().

evolve: use repo.setparents() instead of repo.dirstate.setparents() setparents() was added to localrepository class in 2012, and now we finally have some differences between calling repo.setparents() vs repo.dirstate.setparents(): _quick_access_* things, introduced in hg 5.3. This patch fixes an actual quick-access desync problem where repo[b'.'] would be different from repo.dirstate.p1(), as demonstrated by test-evolve-phase-divergence.t when ran on hg 5.3rc0 and later. Modified _uncommitdirstate() too, because it is used in dirstatedance(), which sometimes follows repo.setparents() calls.

tests: demonstrate that evolve swaps parents of merge commits Tests currently pass, don't forget to change FIXME items.

ci: cache pytype-related files between runs

evolve: add pre-check logic for creation of phase divergence locally Changes in tests reflect the added behaviour.

evolve: add test to show that user can create phase-divergence locally After resolution of phase-divergence, user can locally create phase-divergence by rewriting the old bumped (obsolete now) changeset. Next patch will be adding the pre-check logic for creation of this phase-divergence.

evolve: remove unnecessary code since it's been covered already We don't need this logic any more since the case of "two divergent csets where one is the parent of other" has been handled correctly by the logic present in method _prepcontentdivresolution() This is how things works in method _prepcontentdivresolution() for our case i.e "content-divergence with parent-child relation": cset_b (content-divergent) | cset_a (content-divergent) | ~ Acc. to revision selection criteria: "divergent" = min_revision(cset_a, cset_b) So always "divergent" will be cset_a and "other" will be "cset_b" and resolution parent will be the successor of parent of cset_a Both the csets will be merged and resolution cset will be based on correct revision. The result could be wrong only in the case when "divergent" is cset_b which is not possible acc. to the current logic.

test: no need to look at full log

evolve: refactor content-divergence resolution logic > What is the case we are looking at? This is about refactoring the part of content-div resolution logic where it decides which cset should be relocated and where. > What is a "topologicial common ancestors" vs a "greatest common ancestors"? `tca` is an ancestor which we can decide/find by looking at the at graph visually for e.g ``` c3(*) c4(*) | | c2(x) c1(x) c5 | / \ | / c0 ``` (c5 is the successor of c2 and c1) now here, `tca` of c3 and c4 is: c0 `gca` of c3 and c4 is: c5 > What is the new top-level logic/behavior that makes it better? The old code had some unnecessary edge cases just because we were using `gca`, since it can point to a revision that is not a topological ancestor. For e.g see b779b40f996e Eventually, the code around this was getting messy unnecessarily. So I looked into it and found a simple and more robust approach. And in new code, it is simple and straightforward (and easy to understand), where we handle the following 4 cases when solving content-div: 1) when both are on the same parent => (no need to do anything special, and simply proceed) 2) both are on the different parent but a) `tca` is the parent of one of them or b) there is no non-obsolete revision between `tca` and one of the divergent cset. => (relocate one to the other side and proceed) 3) both are on different parents and `tca` is not the parent of any of them and there is at least one non-obsolete cset between tca and both the divergent cset i.e (tca::div1) and (tca::div2) both the ranges have at least one non-obs revision. => (this is the case which we don't handle yet, but the solution would be to prompt the user to choose an evolve destination.) 4) both are in the parent-child relation => (both are merged and new cset will be based on the successor of `tca`) Changes in test-evolve-issue5958.t demonstrate that new code also covered case4 because in a resolution of "two divergent csets with parent-child relation" there should be one cset as a result and no orphan revs (as you can see there was an orphan before this patch).

evolve: remove duplicated code See at line 500.

evolve: make necessary changes in a test to reflect a fix in next patch

evolve: add quotes around the action in msg of pre-checking

metaedit: use pre-checking before rewriting csets Changes in test file demonstrate the changed behaviour.

evolve: update the pre-check message for risk of orphans

evolve: add pre-check logic for creation of phase divergence locally Changes in tests reflect the added behaviour.

evolve: add test to show that user can create phase-divergence locally After resolution of phase-divergence, user can locally create phase-divergence by rewriting the old bumped (obsolete now) changeset. Next patch will be adding the pre-check logic for creation of this phase-divergence.

evolve: remove a check which is already done by rewriteutil.precheck() We have tests to check if fold is being performed on public cset. There is no changes in test files because testing that never touched the part this patch removes, and already caught in rewriteutil.precheck()

evolve: add pre-check logic for content-divergence in rewriteutil.precheck() For now, pre-check will abort if rewriting a rev create divergence (and config experimental.evolution.allowdivergence is not set to True). But this behaviour can be improved where instead of abort maybe we can confirm the user to either proceed with divergence or some other options depends on what command user is running. Changes in test file are used to overrides the pre-check for testing purpose (using experimental.evolution.allowdivergence=yes).

topic: make in-memory rebase preserve topic The override code thought that `__init__` would return the runtime instance, but it's actually the first argument to the function (the `self` argument), so the code had no effect at all before this patch. I think the bug only affected in-memory rebase because the in-working-copy rebase used the current topic, which was set correctly since 5156a67f66a6 (topics: update current topic to the topic of newly rebased commit (issue5551), 2017-06-29).

Temporary commit for time measurement of test file + pandoc

ci: Add CI job for building the documentation

tutorial: compile the tutorial in rst so it can be included

tutorial: run the tutorial test file to update to latests ui messages