Skip to content
Snippets Groups Projects
  1. Jul 17, 2019
    • Taapas Agrawal's avatar
      continue: added support for unshelve · 117437f3f541
      Taapas Agrawal authored
      This patch adds the support for `ushelve` in `hg continue` plan.
      
      `hgcontinueunshelve()` has been created for independent calls.
      In case an interrupted unshelve is resumed via hg continue the
      shelvedstate needs to be loaded seperately. This has been
      ensured by `_loadunshelvedstate()`
      
      `hgcontinueunshelve()` is then registered as `continuefunc` for state
      detection API.
      
      Results are shown as tests.
      
      Differential Revision: https://phab.mercurial-scm.org/D6652
      117437f3f541
  2. Jul 15, 2019
    • Taapas Agrawal's avatar
      continue: added support for rebase · 35ebdbb38efb
      Taapas Agrawal authored
      This adds support of rebase to hg continue plan.
      
      An independent continue logic for rebase is created
      under continuerebase() function. For this a seperate
      rebaseruntime object is created under the function to
      handle an interrupted rebasestate.
      
      Results of tests are shown.
      
      Differential Revision: https://phab.mercurial-scm.org/D6646
      35ebdbb38efb
    • Taapas Agrawal's avatar
      continue: added logic for hg continue · 3c16b9c0b099
      Taapas Agrawal authored
      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
      3c16b9c0b099
  3. Jul 17, 2019
  4. Jul 10, 2019
  5. Jul 02, 2019
    • Raphaël Gomès's avatar
      rust: switch hg-core and hg-cpython to rust 2018 edition · 326fdce22fb2
      Raphaël Gomès authored
      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
      326fdce22fb2
  6. Jul 12, 2019
  7. Jul 16, 2019
  8. Jul 15, 2019
  9. Jul 12, 2019
  10. Jul 10, 2019
  11. Jul 13, 2019
    • Martin von Zweigbergk's avatar
      py3: source-transform only call-sites of iteritems(), not definitions · 3018749a71bb
      Martin von Zweigbergk authored
      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
      3018749a71bb
  12. Jul 15, 2019
  13. Jul 14, 2019
  14. Jun 29, 2019
    • Taapas Agrawal's avatar
      abort: added support for merge · 3bc400ccbf99
      Taapas Agrawal authored
      This adds support of `hg merge --abort` to `hg abort` plan.
      
      This involves refactoring `hg.merge` into two different
      functions removing the abort logic of `merge` from `hg.merge`
      and then creating a seperate `hg.abortmerge` to handle the
      abort logic so that the abortion of merge can be called
      independently.
      
      `hg.abortmerge` is then registered as `abortfunc` for the
      state detection API so that `commands.abort` can use it to
      deal with an unfinished merge operation.
      
      Results are shown as tests.
      
      Differential Revision: https://phab.mercurial-scm.org/D6588
      3bc400ccbf99
  15. Jun 26, 2019
    • Taapas Agrawal's avatar
      abort: added support for unshelve · 3fb0493812c0
      Taapas Agrawal authored
      This patch adds the support for shelve in `hg abort` plan.
      
      For this the logic to load a `shelvedstate` and the error
      handling for it had been shifted to a seperate function
      `_loadunshelvedstate()`. This returns a tuple with `state` file
      and `opts.`
      
      `hgabortunshelve()` has been created for independent calls.
      In case abortion of `unshelve` is called via `hg abort` the
      `shelvedstate` needs to be loaded seperately. This has been
      ensured by `_loadunshelvedstate()`
      
      `hgabortunshelve()` is then registered as `abortfunc` for state
      detection API.
      
      Results are shown as tests.
      
      Differential Revision: https://phab.mercurial-scm.org/D6579
      3fb0493812c0
  16. Jul 10, 2019
  17. Jun 19, 2019
  18. Jul 09, 2019
  19. Jun 28, 2019
    • Martin von Zweigbergk's avatar
      copies: follow copies across merge base without source file (issue6163) · 819712deac69
      Martin von Zweigbergk authored
      As in the previous patch, consider these two histories:
      
        @  4 'rename x to y'
        |
        o  3 'add x again'
        |
        o  2 'remove x'
        |
        | o  1 'modify x'
        |/
        o  0 'add x'
      
        @  4 'rename x to y'
        |
        o  3 'add x again'
        |
        | o  2 'modify x'
        | |
        | o  1 'add x'
        |/
        o  0 'base'
      
      We trace copies from the 'modify x' commit to commit 4 by going via
      the merge base (commit 0). When tracing file 'y' (_tracefile()) in the
      first case, we immediately find the rename from 'x'. We check to see
      if 'x' exists in the merge base, which it does, so we consider it a
      valid copy. In the second case, 'x' does not exist in the merge base,
      so it's not considered a valid copy. As a workaround, this patch makes
      it so we also attempt the check in mergecopies's base commit (commit 1
      in the second case). That feels pretty ugly to me, but I don't have
      any better ideas.
      
      Note that we actually also check not only that the filename matches,
      but also that the file's nodeid matches. I don't know why we do that,
      but it was like that already before I rewrote mergecopies(). That
      means that the rebase will still fail in cases like this (again, it
      already failed before my rewrite):
      
      
        @  4 'rename x to y'
        |
        o  3 'add x again with content X2'
        |
        o  2 'remove x'
        |
        | o  1 'modify x to content X2'
        |/
        o  1 'modify x to content X1'
        |
        o  0 'add x with content X0'
      
      Differential Revision: https://phab.mercurial-scm.org/D6604
      819712deac69
  20. Jun 25, 2019
    • Martin von Zweigbergk's avatar
      copies: filter invalid copies only at end of pathcopies() (issue6163) · d013099c551b
      Martin von Zweigbergk authored
      copies._filter() filters out copies whose source file does not exist
      in the start commit or whose target file does not exist in the end
      commit. We do that after chaining copies with dirstate copies or
      backward renames from another branch. We also do at the end of the
      changeset-centric copy tracing. The filtering means that we will
      remove copies to/from files that did not exist in some intermediate
      commit. That is inconsistent with what we do if a file has been
      deleted and then re-added (we allow updating across that).
      
      Copying the two first examples from issue6163:
      
        @  4 'rename x to y'
        |
        o  3 'add x again'
        |
        o  2 'remove x'
        |
        | o  1 'modify x'
        |/
        o  0 'add x'
      
        @  4 'rename x to y'
        |
        o  3 'add x again'
        |
        | o  2 'modify x'
        | |
        | o  1 'add x'
        |/
        o  0 'base'
      
      When doing `hg rebase -r 1 -d 4` in the first case, it succeeds, but
      `hg rebase -r 2 -d 4` in the second case does not. That's because we
      chain and filter via commit 0, which does not have file 'x' in the
      second case. IMO, that's clearly inconsistent. So this patch removes
      the filtering step so it only happens at the end. If a file was
      temporarily removed, whether via a merge base or not, it will now
      still be considered the same file. That fixes issue6163 for the
      changeset-centric case.
      
      Differential Revision: https://phab.mercurial-scm.org/D6603
      d013099c551b
    • Martin von Zweigbergk's avatar
    • Martin von Zweigbergk's avatar
      copies: remove most early returns from pathcopies() and _forwardcopies() · a48f6f18dc6d
      Martin von Zweigbergk authored
      I want to split up _chainandfilter() more so the call to _filter()
      consistently happens at the end of pathcopies(). This prepares for
      that change.
      
      Differential Revision: https://phab.mercurial-scm.org/D6601
      a48f6f18dc6d
  21. Jun 28, 2019
    • Martin von Zweigbergk's avatar
      copies: move short-circuiting of dirstate copies out of _forwardcopies() · bcb4b5c5964b
      Martin von Zweigbergk authored
      I'd like to move the filtering of copies we do after chaining to the
      end of all chaining (in a single place in pathcopies()). One problem
      that came up when trying that was that we allow things like `hg cp -f
      <file> <existing file>` so the user can later amend that in. Filtering
      at the end would mean that we remove those copies. That would break
      `hg st -C`. This patch therefore moves the short-circuiting of
      dirstate copies into pathcopies() so we can more easily handle the
      dirstate-only case differently.
      
      I initially thought this might change some behavior when the user does
      `hg status --rev 'wdir()' --rev .` during an uncommitted merge, since
      _backwardrenames() would reverse the copies in that case. However, I
      couldn't come up with a test case where it made a difference.
      
      Differential Revision: https://phab.mercurial-scm.org/D6600
      bcb4b5c5964b
  22. Jun 21, 2019
    • Martin von Zweigbergk's avatar
      tests: add more tests of copy tracing with removed and re-added files · ab416b5d9b91
      Martin von Zweigbergk authored
      We had a test where the destination of a copy was removed and then
      added back. This patch adds similar cases where the break in history
      instead happens to the source file. There are three versions of this:
      
       1. The break happens before the rename.
      
       2. The break happens on a branch parallel to the rename (where copy
          tracing is done via the merge base)
      
       3. The source is added on each side of the merge base. The break in
          history is thus in the form of a deletion when going backwards to
          the merge base and the re-add happens on the other branch.
      
      I've also added calls to `hg graft` in these cases to show the
      breakage in issue 6163.
      
      Another factor in these cases is matching nodeid (checked in
      copies._tracefile()). I've made two copies each of the cases to show
      the impact of that. One of these is the same as a test in
      test-rename-merge1.t, so I also deleted that test from there.
      
      Some of these tests currently fail, where "fail" is based on my
      current thinking of how things should work. I had initially thought
      that we should be more strict about not tracing copies across commits
      where the file did not exist, but issue 6163 made me reconsider.
      
      The only test case here that behaved differently in 4.9 is the
      exact case reported in issue 6163.
      
      Differential Revision: https://phab.mercurial-scm.org/D6599
      ab416b5d9b91
  23. Jul 01, 2019
  24. Jun 24, 2019
  25. Jun 30, 2019
  26. Jul 10, 2019
  27. Jun 27, 2019
    • Taapas Agrawal's avatar
      abort: added support for histedit · db5560c07a28
      Taapas Agrawal authored
      This patch adds the support for `histedit` in `hg abort` plan.
      
      As seperate `hgaborthistedit()` function is created to handle
      independent calls for abortion of `histedit`. This function is
      then registered as `abortfunc` for state detection API.
      
      hg abort in case of `histedit` also supports ` history-editing-backup`
      config option.
      
      Results are shown as tests.
      
      Differential Revision: https://phab.mercurial-scm.org/D6582
      db5560c07a28
  28. Jun 23, 2019
    • Taapas Agrawal's avatar
      abort: added support for rebase · b9bc47211cf5
      Taapas Agrawal authored
      This adds support of `rebase` to `hg abort` plan.
      
      An independent abort logic for `rebase` is created
      under `abortrebase()` function. For this a seperate
      `rebaseruntime` object is created under the function to
      handle an unfinished `rebasestate` and abort that using
      abort logic under `_prepareabortorcontinue`.
      
      Results of tests are shown.
      
      Differential Revision: https://phab.mercurial-scm.org/D6568
      b9bc47211cf5
    • Taapas Agrawal's avatar
      abort: added support for graft · 5171937ad0f9
      Taapas Agrawal authored
      This adds support of `graft` to `hg abort` plan.
      
      The patch creates a seperate function `cmdutil.hgabortgraft`
      so that abort logic for graft can be called independently.
      This logic is registered to the statedetection API as `abortfunc`.
      
      Results are shown as tests.
      
      Differential Revision: https://phab.mercurial-scm.org/D6567
      5171937ad0f9
    • Taapas Agrawal's avatar
      abort: added logic for of hg abort · bb135a784b70
      Taapas Agrawal authored
      This is part of `GSoC19` project `Implement abort and
      continue commands`. This patch is part of the `abort plan`.
      
      This adds the basic logic for `hg abort`. This command
      aborts an multistep operation like graft, histedit, rebase,
      merge 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 abort` by adding a method
      to register the abort logic as a function (here `abortfunc`).
      
      Once the unfinished operation is determined the registered
      logic is used to abort the command. The benefit of this kind
      of framework is that any new extension developed can support
      `hg abort` by registering the command and logic under
      statedetection API.
      
      `hg abort` currently supports `--dry-run/-n` flag only.
      It is used to dry run `hg abort`
      
      Further patches sequentially add support for `graft`, `rebase`,
      `unshelve`, `histedit` and `merge`.
      
      Differential Revision: https://phab.mercurial-scm.org/D6566
      bb135a784b70
  29. Jul 09, 2019
  30. Jul 08, 2019
  31. Jul 04, 2019
  32. Jul 08, 2019
Loading