Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. Feb 20, 2023
    • Pierre-Yves David's avatar
      dirstate: invalidate on all exceptions · 2323b74f927b
      Pierre-Yves David authored
      Previously, we would miss SystemExit, KeyboardInterrupt etc.
      
      This "fix" on the bug tested in "test-largefiles-update.t" by preventing the
      precisely tested situation to happens at all. However this reveal a similar bug
      with a different timing.
      
      I have not been able to deal with that pre-existing bug so far. So I updated the
      test to point that out.
      2323b74f927b
  3. Feb 21, 2023
  4. Nov 17, 2021
  5. Oct 22, 2020
    • 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
      https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. 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
      codes.
      
      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
      works.
      
      Differential Revision: https://phab.mercurial-scm.org/D9238
      21733e8c924f
  6. Oct 27, 2020
  7. Jul 13, 2020
  8. Jun 24, 2019
  9. Jun 20, 2019
    • 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
  10. Nov 01, 2018
  11. Oct 31, 2018
    • Boris Feld's avatar
      tests: adjust merge tool config in test-largefiles-update.t · 37e75be0b019
      Boris Feld authored
      Previously, the `ui.merge=internal:fail` configuration was shadowed by the the
      `HGMERGE=internal:merge` environment variable. We would like to remove this
      usage of `HGMERGE` variable because it is error-prone (eg: this very test). We
      start by cleaning up test independently to avoid large churn when the change
      happens.
      37e75be0b019
  12. Sep 21, 2018
  13. Aug 29, 2018
    • Boris Feld's avatar
      phase: report number of non-public changeset alongside the new range · 89630d0b3e23
      Boris Feld authored
      When interacting with non-publishing repository or bundle, it is useful to
      have some information about the phase of the changeset we just pulled.
      
      This changeset updates the "new changesets MIN:MAX" output to also includes
      phases information for non-public changesets. Displaying extra data about
      non-public changesets means the output for exchange with publishing repository
      (the default) is unaffected.
      89630d0b3e23
  14. Aug 26, 2018
  15. Aug 25, 2018
  16. Aug 20, 2018
  17. Apr 03, 2018
  18. Jan 28, 2018
    • Matt Harbison's avatar
      revset: evaluate filesets against each revision for 'file()' (issue5778) · f6ca1e11d8b4
      Matt Harbison authored
      After f2aeff8a87b6, the fileset was evaluated to a set of files against the
      working directory, and then those files were applied against each revision.  The
      result was nonsense.  For example, `hg log -r 'file("set:exec()")'` on the
      Mercurial repo listed revision 0 because it has the `hg` script, which is
      currently +x.  But that bit wasn't applied until revision 280 (which
      'contains()' properly indicates).
      
      This technique was borrowed from checkstatus(), which services adds(),
      modifies(), and removes(), so it seems safe enough.  The 'r:' case is explicitly
      assigned to wdirrev, freeing up rev=None to mean "re-evaluate at each revision".
      The distinction is important to avoid behavior changes with `hg log set:...`
      (test-largefiles-misc.t and test-fileset-generated.t drop current log output
      without this).  I'm not sure what the right behavior for that is (1fd352aa08fc
      explicitly enabled this behavior for graphlog), but the day before the release
      isn't the time to experiment.
      f6ca1e11d8b4
  19. Jan 08, 2018
    • 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
      etc.
      
      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: https://phab.mercurial-scm.org/D1829
      41ef02ba329b
  20. Dec 11, 2017
    • 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
      Linux.
      
        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:
                        dst.write(line)
                        continue
                    if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
                        dst.write(line)
                        continue
                    dst.write(m.group(1) + m.group(2) + '\n')
            os.unlink(p)
            os.rename(tmp, p)
      4441705b7111
  21. Dec 03, 2017
    • Matt Harbison's avatar
      tests: add a substitution for ENOENT/ERROR_FILE_NOT_FOUND messages · feecfefeba25
      Matt Harbison authored
      Automatic replacement seems better than trying to figure out a check-code rule.
      I didn't bother looking to see why the error message and file name is reversed
      in the annotate and histedit tests, based on Windows or not.
      
      I originally had this as a list of tuples, conditional on the platform.  But
      there are a couple of 'No such file or directory' messages emitted by Mercurial
      itself, so unconditional is required for stability.  There are also several
      variants of what I assume is 'connection refused' and 'unknown host' in
      test-clone.t and test-clonebundles.t for Docker, FreeBSD jails, etc.  Yes, these
      are handled by (re) tags, but maybe it would be better to capture those strings
      in order to avoid whack-a-mole in future tests.  All of this points to using a
      dictionary containing one or more strings-to-be-replaced values.
      feecfefeba25
  22. Oct 12, 2017
    • Denis Laxalde's avatar
      transaction-summary: show the range of new revisions upon pull/unbundle (BC) · eb586ed5d8ce
      Denis Laxalde authored
      Upon pull or unbundle, we display a message with the range of new revisions
      fetched. This revision range could readily be used after a pull to look out
      what's new with 'hg log'. The algorithm takes care of filtering "obsolete"
      revisions that might be present in transaction's "changes" but should not be
      displayed to the end user.
      eb586ed5d8ce
  23. Jul 08, 2017
  24. Jun 06, 2017
  25. Jan 30, 2017
    • Augie Fackler's avatar
      tests: correct (I think) command in test-largefiles-update · 2d6b86cadc10
      Augie Fackler authored
      When this test was introduced, it used the short-form of all the flags
      on this update invocation. I suspect, based on the "start with clean
      dirstates" comment and the fact that the no-exec branch of the #if
      guard leaves dirstate clean, that this should have been 'update -qCr'
      instead of 'update -qcr', but that a bug in largefiles --check
      handling left this problem unnoticed.
      
      I'll leave a breadcrumb further up about the current failure mode in
      the hopes that we can fix this some day.
      
      This was previously discussed in [0] but the trail in that thread goes
      cold after a few replies. Given that this is still a flaky test, that
      appears to only be passing by bad fortune, I think it's worth
      correcting the code of the test to make a correct assertion, and to
      keep track of the suspected bug with some other mechanism than an
      invalid test (if we had support for "expected failure" blocks this
      might be a worthwhile use of them?).
      
      0: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089501.html
      2d6b86cadc10
    • Augie Fackler's avatar
      tests: expand flags to long form in test-largefiles-update.t · 6cd99ec908fa
      Augie Fackler authored
      I spent some time confused by this test. I'm pretty sure that this
      line intends to be cleaning the dirstate, not checking that it's clean
      before updating: the preceding #if block leaves the dirstate clean in
      the noexec case, and dirty in the exec case, so we can't expect
      consistent behavior across that platform variation. A subsequent patch
      will modify this command to use --clean instead of --check.
      
      I'll elaborate in that patch about the hypothetical bug here.
      6cd99ec908fa
  26. Oct 29, 2016
    • Katsunori FUJIWARA's avatar
      tests: put temporary file outside the working directory for test portability · 6e04f4ec4875
      Katsunori FUJIWARA authored
      test-largefiles-update.t creates temporary file exec-bit.patch inside
      the working directory for no-execbit platform specific test, but
      subsequent tests aren't aware of it.
      
      On execbit platform, subsequent tests can run successfully, because
      exec-bit.patch isn't created.
      
      But on no-execbit platform, this temporary file makes subsequent tests
      show "? exec-bit.patch" at each "hg status".
      6e04f4ec4875
  27. Oct 18, 2016
  28. Oct 17, 2016
    • Mads Kiilerich's avatar
      largefiles: fix 'deleted' files sometimes persistently appearing with R status · 328545c7d8a1
      Mads Kiilerich authored
      A code snippet that has been around since largefiles was introduced was wrong:
      Standins no longer found in lfdirstate has *not* been removed -
      they have probably just been deleted ... or not created.
      
      This wrong reporting did that 'up -C' didn't undo the change and didn't sync
      the two dirstates.
      
      Instead of reporting such files as removed, propagate the deletion to the
      standin file and report the file as deleted.
      328545c7d8a1
  29. Oct 16, 2016
    • Mads Kiilerich's avatar
      largefiles: more safe handling of interruptions while updating modifications · 56b930238036
      Mads Kiilerich authored
      Largefiles are fragile with the design where dirstate and lfdirstate must be
      kept in sync.
      
      To be less fragile, mark all clean largefiles as unsure ("normallookup") before
      updating standins. After standins have been updated and we know exactly which
      largefile standins actually was changed, mark the unchanged largefiles back to
      clean ("normal").
      
      This will make the failure mode more safe. If interrupted, the next command
      will continue to perform extra hashing of all largefiles. That will do that all
      largefiles that are out of sync with their standin will be marked dirty and
      they will show up in status and can be cleaned with update --clean.
      56b930238036
    • Mads Kiilerich's avatar
      largefiles: test coverage of fatal interruption of update · 4999c12c526b
      Mads Kiilerich authored
      Test using existing changesets in a clean working directory, revealing problems
      with files that don't show up as modified or do show up as removed when they
      just not have been written yet.
      4999c12c526b
  30. Oct 08, 2016
  31. Aug 12, 2016
    • Simon Farnsworth's avatar
      merge: always use other, not remote, in user prompts · 978b907d9b36
      Simon Farnsworth authored
      Now that we store and display merge labels in user prompts (not just
      conflict markets), we should rely on labels to clarify the two sides of a
      merge operation (hg merge, hg update, hg rebase etc).
      
      "remote" is not a great name here, as it conflates "remote" as in "remote
      server" with "remote" as in "the side of the merge that's further away". In
      cases where you're merging the "wrong way" around, remote can even be the
      "local" commit that you're merging with something pulled from the remote
      server.
      978b907d9b36
    • Simon Farnsworth's avatar
      merge: use labels in prompts to the user · a7f8939641aa
      Simon Farnsworth authored
      Now that we persist the labels, we can consistently use the labels in
      prompts for the user without risk of confusion. This changes a huge amount
      of command output:
      
      This means that merge prompts like:
        no tool found to merge a
        keep (l)ocal, take (o)ther, or leave (u)nresolved? u
      and
        remote changed a which local deleted
        use (c)hanged version, leave (d)eleted, or leave (u)nresolved? c
      become:
        no tool found to merge a
        keep (l)ocal [working copy], take (o)ther [destination], or leave (u)nresolved? u
      and
        remote [source] changed a which local [dest] deleted
        use (c)hanged version, leave (d)eleted, or leave (u)nresolved? c
      where "working copy" and "destination" were supplied by the command that
      requested the merge as labels for conflict markers, and thus should be
      human-friendly.
      a7f8939641aa
  32. Feb 08, 2016
    • Katsunori FUJIWARA's avatar
      tests: use portable diff script via extdiff extension · b59ef0c21405
      Katsunori FUJIWARA authored
      Before this patch, some tests using external "diff" command via
      extdiff extension fail on Solaris, because of incompatibility of
      "diff" command and its output.
      
      For example, system standard "diff" (= /usr/bin/diff) on Solaris
      differs from GNU diff in points below:
      
        - "-N" (treat absent files as empty) option isn't supported
      
        - files are examined not in dictionary order
          (maybe, in order in storage)
      
      This patch introduces portable diff script "pdiff" and make tests use
      it via extdiff extension.
      
      For portability of tests, this patch invokes "pdiff" script with
      explicit "sh", because standard shell of runtime platform ("cmd.exe"
      on Windows) is used at first to invoke external diff command.
      b59ef0c21405
    • Katsunori FUJIWARA's avatar
      tests: make chunk header of external diff glob-ed for portability · c65da6892ae5
      Katsunori FUJIWARA authored
      Before this patch, some tests using external "diff" command via
      extdiff extension fail on Solaris, because system standard "diff" (=
      /usr/bin/diff) on Solaris always formats chunk header in the style
      below:
      
        @@ -X.x +Y.y @@
      
      even though "diff" on Linux sometimes omits ".x" and/or ".y" in it.
      
      This patch makes chunk header of external diff glob-ed for portability
      of tests, and adds check-code.py rules to detect such diff output in
      tests.
      
      This patch also changes "hg diff" output in test-subrepo-git to
      simplify detection rules, even though it is certainly portable because
      these lines are generated by "git" command.
      
      This patch is a part of making tests using external "diff" portable,
      and tests below aren't yet portable even after this patch.
      
        test-largefiles-update.t
        test-subrepo-deep-nested-change.t
      c65da6892ae5
    • Katsunori FUJIWARA's avatar
      tests: omit -p for external diff via extdiff extension for portability · 0707bbec682d
      Katsunori FUJIWARA authored
      Before this patch, some tests using external "diff" command via
      extdiff extension fail on Solaris, because "-p" (show which C function
      each change is in) option isn't supported by system standard "diff" on
      Solaris, even though extdiff passes it to external "diff" by default.
      
      Fortunately, this non-portable option isn't important for (current, at
      least) tests using external "diff" command via extdiff extension.
      
      This patch omits "-p" for external "diff" command via extdiff
      extension for portability of tests, and adds check-code.py a rule to
      detect invocation of "diff" with "-p".
      
      Newly added check-code.py rule examines only lines generated by
      external "diff" with "-r", because strict examination might
      misidentify "hg diff -p" or other complicated lines consisting of
      "diff" string as wrong one.
      
      This patch is a part of making tests using external "diff" portable,
      and tests below aren't yet portable even after this patch.
      
        test-graft.t
        test-largefiles-update.t
        test-subrepo-deep-nested-change.t
      0707bbec682d
  33. Feb 03, 2016
  34. Feb 02, 2016
    • Pierre-Yves David's avatar
      update: warn about other topological heads on bare update · 72072cfc7e91
      Pierre-Yves David authored
      A concern around the user experience of Mercurial is user getting stuck on there
      own topological branch forever. For example, someone pulling another topological
      branch, missing that message in pull asking them to merge and getting stuck on
      there own local branch.
      
      The current way to "address" this concern was for bare 'hg update' to target the
      tipmost (also latest pulled) changesets and complain when the update was not
      linear. That way, failure to merge newly pulled changesets would result in some
      kind of failure.
      
      Yet the failure was quite obscure, not working in all cases (eg: commit right
      after pull) and the behavior was very impractical in the common case
      (eg: issue4673).
      
      To be able to change that behavior, we need to provide other ways to alert a
      user stucks on one of many topological head. We do so with an extra message after
      bare update:
      
        1 other heads for branch "default"
      
      Bookmark get its own special version:
      
        1 other divergent bookmarks for "foobar"
      
      There is significant room to improve the message itself, and we should augment
      it with hint about how to see theses other heads or handle the situation (see
      in-line comment). But having "a" message is already a significant improvement
      compared to the existing situation. Once we have it we can iterate on a better
      version of it. As having such message is an important step toward changing the
      default destination for update and other nicety, I would like to move forward
      quickly on getting such message.
      
      This was discussed during London - October 2015 Sprint.
      72072cfc7e91
Loading