This instance will be upgraded to Heptapod 0.21.0rc2 on 2021-04-16 at 14:00 UTC+2 (a few minutes of down time)

  1. 22 Oct, 2020 1 commit
  2. 12 Oct, 2020 1 commit
  3. 07 Oct, 2020 1 commit
  4. 22 Oct, 2020 1 commit
    • Martin von Zweigbergk's avatar
      errors: add config that lets user get more detailed exit codes · 21733e8c924f
      Martin von Zweigbergk authored
      This adds an experimental config that lets the user get more detailed
      exit codes. For example, there will be a specific error code for
      input/user errors. This is part of I've made the
      config part of tweakdefaults.
      I've made the config enabled by default in tests. My reasoning is that
      we want to see that each specific error case gives the right exit code
      and we don't want to duplicate all error cases in the entire test
      suite. It also makes it easy to grep the `.t` files for `[255]` to
      find which cases we have left to fix. The logic for the current exit
      codes is quite simple, so I'm not too worried about regressions
      there. I've added a test case specifically for the "legacy" exit
      I've set the detailed exit status only for the case of
      `InterventionRequired` and `SystemExit` for now (the cases where we
      currently return something other than 255), just to show that it
      Differential Revision:
  5. 18 Sep, 2020 1 commit
    • Martin von Zweigbergk's avatar
      mergedriver: delete it · 32ce4cbaec4b
      Martin von Zweigbergk authored
      The merge driver code was added in late 2015. I think
      '406a654b41cb::6f045b563fa5 & user("sid0")' is a reasonable revset for finding
      the relevant commits, including preparation for it. The code is very
      poorly tested, which makes it very hard to maintain. It seems it's
      only used by FB and they don't use this code base anymore, so let's
      remove the code to make it easier for us to maintain our product.
      Differential Revision:
  6. 13 Jul, 2020 1 commit
  7. 24 Aug, 2020 1 commit
  8. 18 May, 2020 1 commit
  9. 20 Jun, 2019 1 commit
    • 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
       rev], or leave (u)nresolved for some/long/dir/name/that/do
      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
      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
      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:
  10. 02 Nov, 2018 1 commit
    • Kyle Lippincott's avatar
      resolve: when resolve.mark-check=abort, downgrade to warning if pats specified · da2e874fe582
      Kyle Lippincott authored
      Previously, with --config resolve.mark-check=abort, running `hg resolve -m foo`
      would abort and emit a message saying to use --all.  This command does not work,
      though: `hg resolve -m foo --all`, and it's really weird for --all to be the
      "--force" flag.
      My original goal with the option was to make it so that `hg resolve -m` (no
      filename arguments) was safer, which is why --all is used; in my mind, `hg
      resolve -m foo` should always mark it as resolved, and `--all` is how you
      specify "all the files", so that's why I chose `hg resolve -m --all` as the way
      out of `hg resolve -m` aborting. This commit makes all of this work the way it
      was meant to in my head :)
      Differential Revision:
      branch : stable
  11. 07 Nov, 2018 1 commit
  12. 21 Aug, 2019 1 commit
  13. 01 Jul, 2018 1 commit
  14. 14 Feb, 2020 1 commit
    • Martin von Zweigbergk's avatar
      debugmergestate: make templated · acbfa31cfaf2
      Martin von Zweigbergk authored
      Our IntelliJ team wants to be able to read the merge state in order to
      help the user resolve merge conflicts. They had so far been reading
      file contents from p1() and p2() and their merge base. That is not
      ideal for several reasons (merge base is not necessarily the "graft
      base", renames are not handled, commands like `hg update -m` is not
      handled). It will get especially bad as of my D7827. This patch makes
      the output s a templated. I haven't bothered to make it complete
      (e.g. merge driver states are not handled), but it's probably good
      enough as a start.
      I've done a web search for "debugmergestate" and I can't find any
      indication that any tools currently rely on its output. If it turns
      out that we get bug reports for it once this is released, I won't
      object to backing this patch out on the stable branch (and then
      perhaps replace it by a separate command, or put it behind a new
      The changes in test-backout.t are interesting, in particular this:
        -    other path: foo (node not stored in v1 format)
        +    other path:  (node foo)
      I wonder if that means that we actually read v1 format
      incorrectly. That seems to be an old format that was switched away
      from in 2014, so it doesn't matter now anyway.
      Differential Revision:
  15. 08 Jan, 2018 1 commit
    • Pulkit Goyal's avatar
      merge: add `--abort` flag which can abort the merge · 41ef02ba329b
      Pulkit Goyal authored
      Currently we don't have a good functionality to abort the merge and tell user to
      do `hg update -C .` which can leads to different results if user missed the '.'
      and moreover does not align with other abort functionalities like rebase, shelve
      This patch adds `hg merge --abort` which will abort the ongoing merge and take
      us back to the chagneset where we started from. Works in both cases when merge
      resulted in conflicts and when there were no conflicts.
      .. feature::
          A `--abort` flag to merge command to abort the ongoing merge.
      Differential Revision:
  16. 29 Jan, 2019 1 commit
  17. 11 Dec, 2017 1 commit
    • Matt Harbison's avatar
      tests: remove (glob) annotations that were only for '\' matches · 4441705b7111
      Matt Harbison authored
      # skip-blame because this was mechanically rewritten the following script.  I
      ran it on both *.t and *.py, but none of the *.py changes were proper.  All *.t
      ones appear to be, and they run without addition failures on both Windows and
        import argparse
        import os
        import re
        ap = argparse.ArgumentParser()
        ap.add_argument('path', nargs='+')
        opts = ap.parse_args()
        globre = re.compile(r'^(.*) \(glob\)(.*)$')
        for p in opts.path:
            tmp = p + '.tmp'
            with open(p, 'rb') as src, open(tmp, 'wb') as dst:
                for line in src:
                    m = globre.match(line)
                    if not m or '$LOCALIP' in line or '*' in line:
                    if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
                    dst.write( + + '\n')
            os.rename(tmp, p)
  18. 30 Sep, 2018 1 commit
  19. 01 Sep, 2018 1 commit
  20. 26 Aug, 2018 2 commits
  21. 04 Aug, 2018 1 commit
  22. 05 Aug, 2018 1 commit
  23. 04 Aug, 2018 1 commit
  24. 03 Aug, 2018 1 commit
  25. 31 Jul, 2018 1 commit
    • Sushil Khanchi's avatar
      resolve: add confirm config option · f8732e33bcbc
      Sushil Khanchi authored
      This config setting gives a functionality to confirm before
      it re-merge all unresolved files. If this config is enabled,
      when you run 'hg resolve --all' it will prompt with a msg
      "re-merge all unresolved files (yn)?"
      To enable this functionality:
      resolve.confirm = True
      Differential Revision:
  26. 27 Jul, 2018 1 commit
    • Kyle Lippincott's avatar
      resolve: add option to warn/abort on -m with unresolved conflict markers · 6c8e3c847977
      Kyle Lippincott authored
      When a user is dropped out of Mercurial to a terminal to resolve files, we emit
      messages like:
          conflicts while merging file1! (edit, then use 'hg resolve --mark')
          conflicts while merging file2! (edit, then use 'hg resolve --mark')
      We don't mention a file name in the hint, so some users might do something like
      `$EDITOR file1; hg resolve --mark`, see that it says "(no more unresolved
      files)" and forget to deal with file2 before running the next command.
      Even if we did mention a file name in the hint, it's too easy to forget it
      (maybe the merge spans a couple days or something). This option lets us inform
      the user that they might have missed something.
      In the scenario above, the output would be something like:
          warning: the following files still have conflict markers:
          (no more unresolved files)
      Differential Revision:
  27. 07 Oct, 2016 1 commit
  28. 03 Mar, 2018 1 commit
  29. 28 Feb, 2018 1 commit
  30. 17 Mar, 2016 1 commit
  31. 24 Dec, 2015 1 commit
  32. 25 Jun, 2017 1 commit
  33. 13 Nov, 2015 1 commit
  34. 15 Oct, 2015 1 commit
    • Siddharth Agarwal's avatar
      commands.resolve: don't allow users to mark or unmark driver-resolved files · c0aab5961876
      Siddharth Agarwal authored
      Users will often be in the habit of running 'hg resolve --mark --all' after
      resolving merge conflicts in source files. We need to make sure this doesn't
      cause driver-resolved files to be marked.
      'hg resolve --all' will resolve driver-resolved files, though.
      The weird conditional structure is to accommodate an upcoming patch.
  35. 08 Dec, 2015 1 commit
    • Martin von Zweigbergk's avatar
      merge: refuse update/merge if there are unresolved conflicts (BC) · 777f668eca70
      Martin von Zweigbergk authored
      We currently allow updating and merging (with --force) when there are
      unresolved merge conflicts, as long as there is only one parent of the
      working copy. Even worse, when updating to another revision
      (linearly), if one of the unresolved files (including any conflict
      markers in the working copy) can now be merged cleanly with the target
      revision, the file becomes marked as resolved.
      While we could potentially allow updates that affect only files that
      are not in the set of unresolved files, that's considerably more work,
      and we don't have a use case for it anyway. Instead, let's keep it
      simple and refuse any merge or update (without -C) when there are
      unresolved conflicts.
      Note that test-merge-local.t explicitly checks for conflict markers
      that get carried over on update. It's unclear if that was intentional
      or not, but it seems bad enough that we should forbid it. The simplest
      way of fixing the test case is to leave the conflict markers in place
      and just mark the files resolved, so let's just do that for now.
  36. 23 Nov, 2015 1 commit
  37. 18 Nov, 2015 1 commit
    • Siddharth Agarwal's avatar
      mergestate: handle additional record types specially · a01ecbcfaf84
      Siddharth Agarwal authored
      This works around a bug in older Mercurial versions' handling of the v2 merge
      We also add a bunch of tests that make sure that
      (1) we correctly abort when the merge state has an unsupported record type
      (2) aborting the merge, rebase or histedit continues to work and clears out the
          merge state.
  38. 19 Nov, 2015 1 commit
  39. 17 Nov, 2015 1 commit