Fri, 15 Nov 2019 11:37:34 +0700 topic: drop compat.getmarkers() and use obsutil.getmarkers() directly
Anton Shestakov <av6@dwimlabs.net> [Fri, 15 Nov 2019 11:37:34 +0700] rev 4942
topic: drop compat.getmarkers() and use obsutil.getmarkers() directly The function in question was moved from obsolete to obsutil in a14e2e7f7d1f (hg 4.3). See also 6aff4bb3970d for hgext3rd/evolve.
Fri, 15 Nov 2019 08:14:06 -0800 cmdrewrite: avoid accessing scmutil.status fields by index
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 08:14:06 -0800] rev 4941
cmdrewrite: avoid accessing scmutil.status fields by index Support for indexed access is going away in Mercurial. Accessing the fields by name is clearer anyway.
Thu, 07 Nov 2019 23:10:26 -0800 obslog: avoid using a formatter after calling end() on it
Martin von Zweigbergk <martinvonz@google.com> [Thu, 07 Nov 2019 23:10:26 -0800] rev 4940
obslog: avoid using a formatter after calling end() on it I don't know if makes a difference, but it feels wrong to use it after calling end(). We can simply use the parent formatter in this case.
Thu, 07 Nov 2019 15:00:57 -0800 obslog: use plural name "effects" for list of all effects
Martin von Zweigbergk <martinvonz@google.com> [Thu, 07 Nov 2019 15:00:57 -0800] rev 4939
obslog: use plural name "effects" for list of all effects Same reasoning as the previous patch, but here the singular was used for the list instead. This patch also renames the variable that represents the list of effects to plural "effects" to reduce confusion.
Thu, 07 Nov 2019 13:21:20 -0800 obslog: use singular name "succnode" for each element of {succnodes}
Martin von Zweigbergk <martinvonz@google.com> [Thu, 07 Nov 2019 13:21:20 -0800] rev 4938
obslog: use singular name "succnode" for each element of {succnodes} The name that we pass for formatlist() is the name of each element. After this patch, you'll write '{succnodes % "{succnode}"}' instead of the confusing '{succnodes % "{succnodes}"}' (where the two "succnodes" refer to different things. Users can write templates that are compatible across this change by using e.g. '{succnodes % "{if(succnode, succnode, succnodes)}"}'.
Mon, 11 Nov 2019 03:40:20 +0700 docs: add SVG figures for sharing.rst stable
Anton Shestakov <av6@dwimlabs.net> [Mon, 11 Nov 2019 03:40:20 +0700] rev 4937
docs: add SVG figures for sharing.rst Generated by graphviz loosely based on .dot files produced by dotgraph extension.
Mon, 11 Nov 2019 03:22:09 +0700 docs: add some up-to-date output from push/pull commands stable
Anton Shestakov <av6@dwimlabs.net> [Mon, 11 Nov 2019 03:22:09 +0700] rev 4936
docs: add some up-to-date output from push/pull commands Hopefully it's going to be helpful for users to better understand how evolve works.
Mon, 11 Nov 2019 02:42:37 +0700 docs: add two more amend commits to simulate temporary amend commits stable
Anton Shestakov <av6@dwimlabs.net> [Mon, 11 Nov 2019 02:42:37 +0700] rev 4935
docs: add two more amend commits to simulate temporary amend commits sharing.rst made reference to temporary amend commits and used them to demonstrate that hidden commits are not exchanged. Nowadays, evolve doesn't create such commits, but it still makes sense to show how they are handled during the exchange process. So let's add two more amend commits, one for each repo. This way the guide doesn't have to be updated too much, but doesn't lose this important detail of working with evolve. Unfortunately, this means that tons of hashes change, but it's better than to have figure 4 demonstrate absolutely nothing. Temporary amend commits were removed from test-sharing.t in 06844693bb21, but sharing.rst continued using them for demonstration purposes. It might've been better to replace at least some of the temporary amend commits by extra amends back then, but oh well.
Mon, 11 Nov 2019 02:33:54 +0700 docs: revision numbers are technically stable stable
Anton Shestakov <av6@dwimlabs.net> [Mon, 11 Nov 2019 02:33:54 +0700] rev 4934
docs: revision numbers are technically stable From `hg help glossary`: "Note that the revision number may be different in each clone of a repository." But cloning the same repo multiple times yields the same result, and that shows that revision numbers are stable.
Sun, 10 Nov 2019 05:14:53 +0700 tests: remove a repeated statement stable
Anton Shestakov <av6@dwimlabs.net> [Sun, 10 Nov 2019 05:14:53 +0700] rev 4933
tests: remove a repeated statement We looked at the review repo just 6 lines above.
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 tip