Skip to content
Snippets Groups Projects
  1. 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
  2. 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
  3. Jul 10, 2019
  4. Jun 19, 2019
  5. Jul 09, 2019
  6. 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
  7. 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
  8. 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
  9. 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
  10. Jul 01, 2019
  11. Jun 24, 2019
  12. Jun 30, 2019
  13. Jul 10, 2019
  14. 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
  15. 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
  16. Jul 09, 2019
  17. Jul 08, 2019
  18. Jul 04, 2019
  19. Jul 08, 2019
  20. Jul 06, 2019
  21. Jun 20, 2019
    • Augie Fackler's avatar
      4eaf7197a740
    • Kyle Lippincott's avatar
      patch: use a short, fixed-size message for last line of prompt (issue6158) · f802a75da585
      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
      f802a75da585
    • Kyle Lippincott's avatar
      filemerge: make last line of prompts <40 english chars (issue6158) · 4764e8436b2a
      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
      4764e8436b2a
  22. Jul 09, 2019
  23. Jul 08, 2019
    • Augie Fackler's avatar
      posix: always seek to EOF when opening a file in append mode · 97ada9b8d51b
      Augie Fackler authored
      Python 3 already does this, so skip it there.
      
      Consider the program:
      
         #include <stdio.h>
      
         int main() {
           FILE *f = fopen("narf", "w");
           fprintf(f, "narf\n");
           fclose(f);
      
           f = fopen("narf", "a");
           printf("%ld\n", ftell(f));
           fprintf(f, "troz\n");
           printf("%ld\n", ftell(f));
      
           return 0;
         }
      
      on macOS, FreeBSD, and Linux with glibc, this program prints
      
         5
         10
      
      but on musl libc (Alpine Linux and probably others) this prints
      
         0
         10
      
      By my reading of
      https://pubs.opengroup.org/onlinepubs/009695399/functions/fopen.html
      this is technically correct, specifically:
      
      > Opening a file with append mode (a as the first character in the
      > mode argument) shall cause all subsequent writes to the file to be
      > forced to the then current end-of-file, regardless of intervening
      > calls to fseek().
      
      in other words, the file position doesn't really matter in append-mode
      files, and we can't depend on it being at all meaningful unless we
      perform a seek() before tell() after open(..., 'a'). Experimentally
      after a .write() we can do a .tell() and it'll always be reasonable,
      but I'm unclear from reading the specification if that's a smart thing
      to rely on. This matches what we do on Windows and what Python 3 does
      for free, so let's just be consistent. Thanks to Yuya for the idea.
      5.0.2
      97ada9b8d51b
  24. Jul 06, 2019
Loading