Skip to content
Snippets Groups Projects
  1. Jul 15, 2019
  2. Jun 29, 2019
    • Taapas Agrawal's avatar
      abort: added support for merge · 3bc400cc
      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
      3bc400cc
  3. Jun 26, 2019
    • Taapas Agrawal's avatar
      abort: added support for unshelve · 3fb04938
      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
      3fb04938
  4. Jul 10, 2019
  5. Jun 19, 2019
  6. Jun 28, 2019
    • Martin von Zweigbergk's avatar
      copies: follow copies across merge base without source file (issue6163) · 819712de
      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
      819712de
  7. Jun 25, 2019
    • Martin von Zweigbergk's avatar
      copies: filter invalid copies only at end of pathcopies() (issue6163) · d013099c
      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
      d013099c
  8. Jun 21, 2019
    • Martin von Zweigbergk's avatar
      tests: add more tests of copy tracing with removed and re-added files · ab416b5d
      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
      ab416b5d
  9. Jul 01, 2019
  10. Jun 24, 2019
  11. Jul 10, 2019
  12. Jun 27, 2019
    • Taapas Agrawal's avatar
      abort: added support for histedit · db5560c0
      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
      db5560c0
  13. Jun 23, 2019
    • Taapas Agrawal's avatar
      abort: added support for rebase · b9bc4721
      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
      b9bc4721
    • Taapas Agrawal's avatar
      abort: added support for graft · 5171937a
      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
      5171937a
    • Taapas Agrawal's avatar
      abort: added logic for of hg abort · bb135a78
      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
      bb135a78
  14. Jul 09, 2019
  15. Jul 08, 2019
  16. Jun 20, 2019
    • Kyle Lippincott's avatar
      patch: use a short, fixed-size message for last line of prompt (issue6158) · f802a75d
      Kyle Lippincott authored
      See issue6158 and the previous commit for examples of what might go wrong if we
      have some combinations of readline version and terminal and need to wrap the
      line.
      
      Briefly: readline may not display the beginning of the last line of the prompt,
      or it may print over it with the end of the prompt, making it difficult for
      users to know what's going on.
      
      Differential Revision: https://phab.mercurial-scm.org/D6563
      f802a75d
    • Kyle Lippincott's avatar
      filemerge: make last line of prompts <40 english chars (issue6158) · 4764e843
      Kyle Lippincott authored
      I've chosen <40 as the target so that other languages that may have a 2x blowup
      in character count can still have a chance to fit into an 80 column screen.
      
      Previously, we would show a prompt like:
      
      ```
      keep (l)ocal [dest], take (o)ther [source], or leave (u)nresolved for some/potentially/really/long/path?
      ```
      
      On at least some systems, if readline was in use then the last line of the
      prompt would be wrapped strangely if it couldn't fit entirely on one line. This
      strange wrapping may be just a carriage return without a line feed, overwriting
      the beginning of the line; example (100 columns wide, 65 character filename, and
      yes there's 10 spaces on the end, I assume this is to handle the user inputting
      longest word we provide as an option, "unresolved"):
      
      ```
      ng/dir/name/that/does/not/work/well/with/readline/file.txt? ave (u)nresolved for some/lon
      ```
      
      In some cases it may partially wrap onto the next line, but still be missing
      earlier parts in the line, such as below (60 columns wide, 65 character
      filename):
      
      ```
       rev], or leave (u)nresolved for some/long/dir/name/that/do
      s/not/work/well/with/readline/file.txt?
      ```
      
      With this fix, this looks like this on a 60 column screen:
      
      ```
      tool vim_with_markers (for pattern some/long/dir/name/that/d
      oes/not/work/well/with/readline/file.txt) can't handle binar
      y
      tool meld can't handle binary
      tool vim_with_markers can't handle binary
      tool internal:merge3 can't handle binary
      tool merge can't handle binary
      no tool found to merge some/long/dir/name/that/does/not/work
      /well/with/readline/file.txt
      file 'some/long/dir/name/that/does/not/work/well/with/readli
      ne/file.txt' needs to be resolved.
      You can keep (l)ocal [working copy], take (o)ther [merge rev
      ], or leave (u)nresolved.
      What do you want to do?
      ```
      
      Differential Revision: https://phab.mercurial-scm.org/D6562
      4764e843
  17. Jun 30, 2019
  18. May 18, 2019
    • Sushil Khanchi's avatar
      commit: add --force-close-branch flag to close a non-head changeset · 2e1d9414
      Sushil Khanchi authored
      While closing branch from a changeset which is not a branch head
      current implementation abort this action in every case but, there
      can be the situations where the changeset is not a local head but
      could be a remote head. This patch adds the functionality to bypass
      the "abort: can only close branch heads" by introducing
      --force-close-branch flag.
      
      Test case changes demonstrate the new functionality added.
      
      Differential Revision: https://phab.mercurial-scm.org/D6490
      2e1d9414
  19. Jun 28, 2019
  20. Jun 08, 2019
    • Taapas Agrawal's avatar
      statecheck: added support for STATES · 12243f15
      Taapas Agrawal authored
      This removes `STATES` from `state.py` and adds support to
      `statecheck` class to handle its features.
      `getrepostate()` function is modified accordingly.
      
      This adds a method 'cmdutil.addunfinished()' for appending to
      the unfinishedstate list so as to keep 'merge' and 'bisect' at the last.
      
      This also makes two separate message formats for `checkunfinished()` and
      `getrepostate()` as there were previously present.
      
      Results of test changed are shown.
      
      Differential Revision: https://phab.mercurial-scm.org/D6503
      12243f15
  21. Jun 24, 2019
  22. Jun 26, 2019
  23. Jun 27, 2019
    • sliquister's avatar
      update: fix spurious unclean status bug shown by previous commit · d29db0a0
      sliquister authored
      The crux of the problem is:
      - the dirstate is corrupted (the sizes/dates are assigned to the wrong files)
      - because when worker.worker is used with a return value (batchget in
        merge.py here), the return value when worker.worker effectively parallelizes
        is permuted
      - this is because worker.worker's partition of input and combination of output
        values are not inverses of one another: it split [1,2,3,4,5,6] into
        [[1,3,5],[2,4,6]], but combines that into [1,3,5,2,4,6].
      
      Given that worker.worker doesn't call its function argument on contiguous
      chunks on the input arguments, sticking with lists means we'd need to
      know the relation between the inputs of worker.worker function argument
      (for instance, requiring that every input element is mapped to exactly
      one output element). It seems better to instead switch return values to
      dicts, which can combined reliably with a straighforward restriction.
      
      Differential Revision: https://phab.mercurial-scm.org/D6581
      d29db0a0
    • sliquister's avatar
      64a873ca
  24. Jun 24, 2019
  25. Jun 23, 2019
  26. Jun 21, 2019
  27. Jun 22, 2019
  28. Jun 21, 2019
    • Pierre-Yves David's avatar
      bookmarks: actual fix for race condition deleting bookmark · 044045dc
      Pierre-Yves David authored
      This is a simple but efficient fix to prevent the issue tested in
      `test-bookmarks-corner-case.t`. It might be worth pursuing a more generic
      approach where filecache learn to depend on each other, but that would not be
      suitable for stable.
      
      The issue is complicated enough that I documented the race and its current
      solution as inline comment. See this comment for details on the fix.
      044045dc
Loading