Mon, 15 Jul 2019 22:23:31 +0530 continue: added logic for hg continue
Taapas Agrawal <taapas2897@gmail.com> [Mon, 15 Jul 2019 22:23:31 +0530] rev 42612
continue: added logic for hg continue This is part of GSoC19 project `Implement abort and continue commands`. This patch is part of the continue plan. This adds the basic logic for hg continue. This command aborts an multistep operation like graft, histedit, rebase, transplant and unshelve if they are in an unfinished state. The first part of the logic is determining the unfinished operation from the state detection API under statemod. This API is extended to support hg continue by adding a method to register the abort logic as a function (here continuefunc). Once the unfinished operation is determined the registered logic is used to resume the command in case it is interrupted. The benefit of this kind of framework is that any new extension developed can support hg continue by registering the command and logic under statedetection API. hg continue currently supports --dry-run/-n flag only. It is used to dry run hg abort Differential Revision: https://phab.mercurial-scm.org/D6645
Wed, 17 Jul 2019 18:15:51 +0200 rust-utils: remove buggy assertion
Raphaël Gomès <rgomes@octobus.net> [Wed, 17 Jul 2019 18:15:51 +0200] rev 42611
rust-utils: remove buggy assertion While this assertion had good intentions, it broke existing behavior with a nasty panic. Differential Revision: https://phab.mercurial-scm.org/D6651
Wed, 10 Jul 2019 17:41:07 +0200 rust-utils: add docstrings and doctests for utils.rs
Raphaël Gomès <rgomes@octobus.net> [Wed, 10 Jul 2019 17:41:07 +0200] rev 42610
rust-utils: add docstrings and doctests for utils.rs Differential Revision: https://phab.mercurial-scm.org/D6635
Tue, 02 Jul 2019 17:15:03 +0200 rust: switch hg-core and hg-cpython to rust 2018 edition
Raphaël Gomès <rgomes@octobus.net> [Tue, 02 Jul 2019 17:15:03 +0200] rev 42609
rust: switch hg-core and hg-cpython to rust 2018 edition Many interesting changes have happened in Rust since the Oxidation Plan was introduced, like the 2018 edition and procedural macros: - Opting in to the 2018 edition is a clear benefit in terms of future proofing, new (nice to have) syntactical sugar notwithstanding. It also has a new non-lexical, non-AST based borrow checker that has fewer bugs(!) and allows us to write correct code that in some cases would have been rejected by the old one. - Procedural macros allow us to use the PyO3 crate which maintainers have expressed the clear goal of compiling on stable, which would help in code maintainability compared to rust-cpython. In this patch are the following changes: - Removing most `extern crate` uses - Updating `use` clauses (`crate` keyword, nested `use`) - Removing `mod.rs` in favor of an aptly named module file Like discussed in the mailing list ( https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-July/132316.html ), until Rust integration in Mercurial is considered to be out of the experimental phase, the maximum version of Rust allowed is whatever the latest version Debian packages. Differential Revision: https://phab.mercurial-scm.org/D6597
Fri, 12 Jul 2019 11:08:31 +0200 rust-utils: use new find_dirs iterator
Raphaël Gomès <rgomes@octobus.net> [Fri, 12 Jul 2019 11:08:31 +0200] rev 42608
rust-utils: use new find_dirs iterator In cad3dde7a573, the `find_dirs` util was introduced, but the second changeset that made use of it didn't apply. This change fixes the issue. Differential Revision: https://phab.mercurial-scm.org/D6639
Tue, 16 Jul 2019 00:00:17 -0400 inno: correct the path display in a literal block of the readme
Matt Harbison <matt_harbison@yahoo.com> [Tue, 16 Jul 2019 00:00:17 -0400] rev 42607
inno: correct the path display in a literal block of the readme Otherwise, the path components allrantogether. Differential Revision: https://phab.mercurial-scm.org/D6648
Mon, 15 Jul 2019 15:29:22 -0700 copies: remove unnecessary override of p[12]copies() in workingctx
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Jul 2019 15:29:22 -0700] rev 42606
copies: remove unnecessary override of p[12]copies() in workingctx The implementation is identical to the version inherited from basectx. Differential Revision: https://phab.mercurial-scm.org/D6647
Fri, 12 Jul 2019 19:38:18 -0400 tests: properly position conditional output on Windows in test-subrepo.t
Matt Harbison <matt_harbison@yahoo.com> [Fri, 12 Jul 2019 19:38:18 -0400] rev 42605
tests: properly position conditional output on Windows in test-subrepo.t The test runner doesn't always guess the right location when optional output is missing. This goes with f6540aba8e3e. Differential Revision: https://phab.mercurial-scm.org/D6640
Thu, 11 Jul 2019 03:08:28 +0530 abort: removed labels argument from abortmerge()
Taapas Agrawal <taapas2897@gmail.com> [Thu, 11 Jul 2019 03:08:28 +0530] rev 42604
abort: removed labels argument from abortmerge() Labels are used to label the code that belongs to `working copy` and `merge rev` in case of a conflicted state. No such labelling is required while aborting merge as conflicted parts are reverted to normal. Differential Revision: https://phab.mercurial-scm.org/D6638
Fri, 12 Jul 2019 23:34:24 -0700 py3: source-transform only call-sites of iteritems(), not definitions
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Jul 2019 23:34:24 -0700] rev 42603
py3: source-transform only call-sites of iteritems(), not definitions branchmap.branchcache, among other classes, defines a iteritems(). That currently gets replaced by items() by the source transformer. That makes it harder for extensions to work with both py2 and py3, since they have to call either items() or iteritems() on branchcache. Let's not replace definitions of iteritems() (and itervalues()) and only replace the call-sites. We need to also add an items() alias to branchcache (etc) so our transformer call-sites will find it. Differential Revision: https://phab.mercurial-scm.org/D6641
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip