Skip to content
Snippets Groups Projects
  1. Jul 01, 2019
  2. Jun 24, 2019
  3. Jun 30, 2019
  4. Jul 10, 2019
  5. 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
  6. 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
  7. Jul 09, 2019
  8. Jul 08, 2019
  9. Jul 04, 2019
  10. Jul 08, 2019
  11. Jul 06, 2019
  12. Jun 20, 2019
    • Augie Fackler's avatar
    • 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
  13. Jul 09, 2019
  14. Jul 08, 2019
    • Augie Fackler's avatar
      posix: always seek to EOF when opening a file in append mode · 97ada9b8
      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.
  15. Jul 06, 2019
  16. Jul 04, 2019
  17. Jul 01, 2019
  18. Jul 03, 2019
  19. Jul 02, 2019
  20. Jul 01, 2019
  21. Jun 30, 2019
  22. Jun 11, 2019
Loading