Skip to content
Snippets Groups Projects
  1. Nov 16, 2018
    • Matt Harbison's avatar
      subrepo: print the status line before creating the peer for better diagnostics · 69d4c8c5c25e
      Matt Harbison authored
      I ran into a problem where I tried updating to a different branch, and the
      process appeared to hang.  It turned out that the subrepo revision wasn't
      available locally, and I must have originally cloned it from an `hg serve -S` on
      a machine that currently wasn't serving anything.  It took 2+ minutes to
      timeout, and didn't mention what it was connecting to even then.
      
      There are a couple of other issues in this scenario too.
      
        - The repo is dirty after the failed checkout because the top level repo is
          updated first.  We should probably make 2 passes- top down to pull
          everything needed, and then do an update once everything is in place.
      
        - Something must be reading .hgsubstate from wdir because if the same merge
          command is run after the timeout, a prompt is issued that the local and
          remote subrepo diverged, instead of hanging.  But it lists the local version
          and remote version as having the same hash.
      69d4c8c5c25e
  2. Aug 05, 2018
    • Yuya Nishihara's avatar
      formatter: rename {abspath}/{file} to {path}, and drop relative {path} (BC) · 34ba47117164
      Yuya Nishihara authored
      Note that {path} in status is either relative-to-cwd or repository-absolute
      depending on the command argument and config knob, which can't be reproduced
      by using the {path|relpath} filter. The default template is updated to always
      use a relative path.
      
      .. bc::
      
         ``{abspath}`` and ``{file}`` in generic templates are renamed to ``{path}``.
         Any ``{path}`` is a repository-absolute path. Use ``{path|relpath}`` to
         convert it to a filesystem path.
      34ba47117164
  3. Jun 19, 2018
  4. 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
  5. 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
  6. Nov 25, 2017
  7. Nov 07, 2017
    • Gregory Szorc's avatar
      subrepo: use per-type config options to enable subrepos · 1a314176da9c
      Gregory Szorc authored
      We change subrepos.allowed from a list of allowed subrepo types to
      a combination of a master switch and per-type boolean flag.
      
      If the master switch is set, subrepos can be disabled wholesale.
      
      If subrepos are globally enabled, then per-type options are
      consulted. Mercurial repos are enabled by default. Everything else
      is disabled by default.
      1a314176da9c
  8. Nov 05, 2017
    • Yuya Nishihara's avatar
      subrepo: extend config option to disable subrepos by type (SEC) · 828cf35f1de6
      Yuya Nishihara authored
      This allows us to minimize the behavior change introduced by the next patch.
      
      I have no idea which config style is preferred in UX POV, but I decided to
      get things done.
      
       a) list: 'allowed = hg, git, svn'
       b) sub option: 'allowed.hg = True' or 'allowed:hg = True'
       c) per-type action: 'hg = allow', 'git = abort'
      828cf35f1de6
    • Yuya Nishihara's avatar
      subrepo: add config option to reject any subrepo operations (SEC) · 5e27afeddaee
      Yuya Nishihara authored
      This is an alternative workaround for the issue5730.
      
      Perhaps this is the simplest way of disabling subrepo operations. It does
      nothing clever, but just aborts if Mercurial starts accessing to a subrepo.
      
      I think Greg's patch is more useful since it allows us to at least check
      out the parent repository. However, that would be confusing if the default
      is flipped to checkout=False and subrepos are silently ignored.
      
      I don't like the config name 'allowed', but I couldn't get any better name.
      5e27afeddaee
  9. Oct 16, 2017
    • Matt Harbison's avatar
      subrepo: share instead of clone if the parent repo is shared (issue5675) (BC) · 68e0bcb90357
      Matt Harbison authored
      Previously, only the top level repo was shared, and then any subrepos were
      cloned on demand.  This is problematic because commits to the parent repo would
      write an updated .hgsubstate to the share source, but the corresponding subrepo
      commit would be stuck in the local subrepo.  That would prevent an update in the
      source repo.  We already go to great lengths to avoid having inconsistent repos
      (e.g., `hg push -r rev` will push _everything_ in a subrepo, even if it isn't
      referenced in one of the parent's outgoing commits).  Therefore, this seems like
      a bug fix, and there's no option to get the old behavior.  I can't imagine the
      previous behavior was useful to anybody.
      
      There shouldn't be an issue with svn, since it is centralized.  Maybe --git-dir
      can be used for git subrepos, but I'll leave that to someone more familiar with
      git.
      
      An integer was previously being implicitly returned from commands.share(), which
      caused dispatch() to start crashing when changing over to returning the shared
      repo.  All error paths appear to raise, so this can be hardcoded to success.
      The clone command checks for 'is None' in a similar pattern, but since
      hg.clone() always returns a tuple, that seems wrong?
      
      .. fix:: Issue 5675
      
         Creating a share of a repository with a Mercurial subrepository will now
         share the subrepository.
      
      and
      
      .. bc::
      
         Mercurial subrepositories are now shared instead of cloned when the parent
         repository is shared.  This prevents dangling subrepository references in the
         share source.  Previously shared repositories with cloned subrepositories
         will continue to function unchanged.
      68e0bcb90357
  10. 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
  11. Aug 07, 2017
    • Yuya Nishihara's avatar
      ssh: unban the use of pipe character in user@host:port string · 3fee7f7d2da0
      Yuya Nishihara authored
      This vulnerability was fixed by the previous patch and there were more ways
      to exploit than using '|shellcmd'. So it doesn't make sense to reject only
      pipe character.
      
      Test cases are updated to actually try to exploit the bug. As the SSH bridge
      of git/svn subrepos are not managed by our code, the tests for non-hg subrepos
      are just removed.
      
      This may be folded into the original patches.
      4.3.1
      3fee7f7d2da0
  12. Jul 31, 2017
    • Sean Farley's avatar
      subrepo: add tests for hg rogue ssh urls (SEC) · 475af2f89636
      Sean Farley authored
      'ssh://' has an exploit that will pass the url blindly to the ssh
      command, allowing a malicious person to have a subrepo with
      '-oProxyCommand' which could run arbitrary code on a user's machine. In
      addition, at least on Windows, a pipe '|' is able to execute arbitrary
      commands.
      
      When this happens, let's throw a big abort into the user's face so that
      they can inspect what's going on.
      475af2f89636
  13. Jul 09, 2017
    • Matt Harbison's avatar
      subrepo: make the output references to subrepositories consistent · 6d88468d435b
      Matt Harbison authored
      Well, mostly.  The annotation on subrepo functions tacks on a parenthetical to
      the abort message, which seems reasonable for a generic mechanism.  But now all
      messages consistently spell out 'subrepository', and double quote the name of
      the repo.  I noticed the inconsistency in the change for the last commit.
      6d88468d435b
  14. Jun 06, 2017
  15. Jun 05, 2017
  16. May 25, 2017
  17. Apr 02, 2017
  18. Mar 20, 2017
  19. Jan 08, 2017
    • Matt Harbison's avatar
      tests: update globs for Windows · d4ec69ff652a
      Matt Harbison authored
      The extra glob in test-command-template.t caused it to say no result was
      reported.  It used to be (within the past year), that both this and the missing
      glob cases could be fixed simply by editing any output in the test, and
      re-running it in interactive mode.  But that no longer works, and I had to diff
      *.t against *.t.err.  I didn't dig into what changed.
      d4ec69ff652a
  20. Nov 30, 2016
    • Jun Wu's avatar
      tests: replace "cp -r" with "cp -R" · c059286a0f9c
      Jun Wu authored
      The POSIX documentation about "cp" [1] says:
      
        ....
      
        RATIONALE
          ....
          Earlier versions of this standard included support for the -r option to
          copy file hierarchies. The -r option is historical practice on BSD and
          BSD-derived systems. This option is no longer specified by POSIX.1-2008
          but may be present in some implementations. The -R option was added as a
          close synonym to the -r option, selected for consistency with all other
          options in this volume of POSIX.1-2008 that do recursive directory
          descent.
      
          The difference between -R and the removed -r option is in the treatment
          by cp of file types other than regular and directory. It was
          implementation-defined how the - option treated special files to allow
          both historical implementations and those that chose to support -r with
          the same abilities as -R defined by this volume of POSIX.1-2008. The
          original -r flag, for historic reasons, did not handle special files any
          differently from regular files, but always read the file and copied its
          contents. This had obvious problems in the presence of special file
          types; for example, character devices, FIFOs, and sockets.
          ....
      
        ....
      
        Issue 6
          The -r option is marked obsolescent.
          ....
      
        Issue 7
          ....
          The obsolescent -r option is removed.
          ....
      
        (No "Issue 8" yet)
      
      Therefore it's clear that "cp -R" is strictly better than "cp -r".
      
      The issue was discovered when running tests on OS X after 0d87b1caed92.
      
      [1]: pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html
      c059286a0f9c
  21. Nov 19, 2016
    • Kostia Balytskyi's avatar
      conflicts: make spacing consistent in conflict markers · ce3a133f71b3
      Kostia Balytskyi authored
      The way default marker template was defined before this patch,
      the spacing before dash in conflict markes was dependent on
      whether changeset is a tip one or not. This is a relevant part
      of template:
          '{ifeq(tags, "tip", "", "{tags} "}'
      If revision is a tip revision with no other tags, this would
      resolve to an empty string, but for revisions which are not tip
      and don't have any other tags, this would resolve to a single
      space string. In the end this causes weirdnesses like the ones
      you can see in the affected tests.
      
      This is a not a big deal, but double spacing may be visually
      less pleasant.
      
      Please note that test changes where commit hashes change are
      the result of marking files as resolved without removing markers.
      ce3a133f71b3
  22. Oct 07, 2016
  23. Oct 08, 2016
  24. Sep 20, 2016
  25. Aug 03, 2016
    • Pierre-Yves David's avatar
      tests: remove all remaining usage of experimental.bundle2-exp · 30c59bdd4f41
      Pierre-Yves David authored
      The only remaining usage of the experimental config were enforcing bundle2 on.
      These are very old remains of when bundle2 was off by default. This was also
      useful to highlight the fact that this was a bundle2 run and that a bundle1 one
      was nearby. However, we want a future developer working on bundle3 to notice
      possible output/behavior change on these tests and take them in account.  So we
      do not enforce bundle2 for these runs. We leave a comment around to make sure
      dev still notice the bundle1 version.
      30c59bdd4f41
    • Pierre-Yves David's avatar
      tests: use 'legacy.exchange' option in various mixed tests · ac9b85079122
      Pierre-Yves David authored
      The new option will stay around. The experimental option was only meant to be
      temporary. We update various tests that validate both bundle1 and bundle2
      version side by side. This changeset only takes care of enforcing bundle1. The
      other use of 'experimental.bundle2-exp=True' will be taken care of in the next
      changeset.
      ac9b85079122
  26. Jul 27, 2016
  27. Jul 22, 2016
  28. Feb 29, 2016
  29. 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
  30. Jan 15, 2016
  31. Nov 25, 2015
  32. Oct 12, 2015
  33. Oct 09, 2015
    • Siddharth Agarwal's avatar
      simplemerge: move conflict warning message to filemerge · ef1eb6df7071
      Siddharth Agarwal authored
      The current output for a failed merge with conflict markers looks something like:
      
        merging foo
        warning: conflicts during merge.
        merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
        merging bar
        warning: conflicts during merge.
        merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
      
      We're going to change the way merges are done to perform all premerges before
      all merges, so that the output above would look like:
      
        merging foo
        merging bar
        warning: conflicts during merge.
        merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
        warning: conflicts during merge.
        merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
      
      The 'warning: conflicts during merge' line has no context, so is pretty
      confusing.
      
      This patch will change the future output to:
      
        merging foo
        merging bar
        warning: conflicts while merging foo! (edit, then use 'hg resolve --mark')
        warning: conflicts while merging bar! (edit, then use 'hg resolve --mark')
      
      The hint on how to resolve the conflicts makes this a bit unwieldy, but solving
      that is tricky because we already hint that people run 'hg resolve' to retry
      unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker
      based resolution.
      ef1eb6df7071
  34. Oct 12, 2015
    • Siddharth Agarwal's avatar
      filemerge: break overall filemerge into separate premerge and merge steps · a5ff66e6d77a
      Siddharth Agarwal authored
      This means that in ms.resolve we must call merge after calling premerge. This
      doesn't yet mean that all premerges happen before any merges -- however, this
      does get us closer to our goal.
      
      The output differences are because we recompute the merge tool. The only
      user-visible difference caused by this patch is that if the tool is missing
      we'll print the warning twice. Not a huge deal, though.
      a5ff66e6d77a
  35. Oct 08, 2015
    • Pierre-Yves David's avatar
      error: get Abort from 'error' instead of 'util' · 56b2bcea2529
      Pierre-Yves David authored
      The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
      confused about that and gives all the credit to 'util' instead of the
      hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
      give back to 'error' the respect it deserves. And screw that 'util' poser.
      
      For great justice.
      56b2bcea2529
  36. Oct 07, 2015
  37. Jul 08, 2015
    • Katsunori FUJIWARA's avatar
      context: write dirstate out explicitly after marking files as clean · fe03f522dda9
      Katsunori FUJIWARA authored
      To detect change of a file without redundant comparison of file
      content, dirstate recognizes a file as certainly clean, if:
      
        (1) it is already known as "normal",
        (2) dirstate entry for it has valid (= not "-1") timestamp, and
        (3) mode, size and timestamp of it on the filesystem are as same as
            ones expected in dirstate
      
      This works as expected in many cases, but doesn't in the corner case
      that changing a file keeps mode, size and timestamp of it on the
      filesystem.
      
      The timetable below shows steps in one of typical such situations:
      
        ---- ----------------------------------- ----------------
                                                 timestamp of "f"
                                                 ----------------
                                                 dirstate   file-
        time          action                     mem  file  system
        ---- ----------------------------------- ---- ----- -----
        N                                              -1    ***
             - make file "f" clean                            N
      
             - execute 'hg foobar'
               - instantiate 'dirstate'           -1   -1
               - 'dirstate.normal("f")'           N    -1
                 (e.g. via dirty check)
               - change "f", but keep size                    N
        N+1
               - release wlock
                 - 'dirstate.write()'             N    N
      
             - 'hg status' shows "f" as "clean"   N    N      N
        ---- ----------------------------------- ---- ----- -----
      
      The most important point is that 'dirstate.write()' is executed at N+1
      or later. This causes writing dirstate timestamp N of "f" out
      successfully. If it is executed at N, 'parsers.pack_dirstate()'
      replaces timestamp N with "-1" before actual writing dirstate out.
      
      Occasional test failure for unexpected file status is typical example
      of this corner case. Batch execution with small working directory is
      finished in no time, and rarely satisfies condition (2) above.
      
      This issue can occur in cases below;
      
        - 'hg revert --rev REV' for revisions other than the parent
        - failure of 'merge.update()' before 'merge.recordupdates()'
      
      The root cause of this issue is that files are changed without
      flushing in-memory dirstate changes via 'repo.commit()' (even though
      omitting 'dirstate.normallookup()' on changed files also causes this
      issue).
      
      To detect changes of files correctly, this patch writes in-memory
      dirstate changes out explicitly after marking files as clean in
      'workingctx._checklookup()', which is invoked via 'repo.status()'.
      
      After this change, timetable is changed as below:
      
        ---- ----------------------------------- ----------------
                                                 timestamp of "f"
                                                 ----------------
                                                 dirstate   file-
        time          action                     mem  file  system
        ---- ----------------------------------- ---- ----- -----
        N                                              -1    ***
             - make file "f" clean                            N
      
             - execute 'hg foobar'
               - instantiate 'dirstate'           -1   -1
               - 'dirstate.normal("f")'           N    -1
                 (e.g. via dirty check)
             ----------------------------------- ---- ----- -----
               - 'dirsttate.write()'              -1   -1
             ----------------------------------- ---- ----- -----
               - change "f", but keep size                    N
        N+1
               - release wlock
                 - 'dirstate.write()'             -1   -1
      
             - 'hg status'                        -1   -1      N
        ---- ----------------------------------- ---- ----- -----
      
      To reproduce this issue in tests certainly, this patch emulates some
      timing critical actions as below:
      
        - timestamp of "f" in '.hg/dirstate' is -1 at the beginning
      
          'hg debugrebuildstate' before command invocation ensures it.
      
        - make file "f" clean at N
        - change "f" at N
      
          'touch -t 200001010000' before and after command invocation
          changes mtime of "f" to "2000-01-01 00:00" (= N).
      
        - invoke 'dirstate.write()' via 'repo.status()' at N
      
          'fakedirstatewritetime.py' forces 'pack_dirstate()' to use
          "2000-01-01 00:00" as "now", only if 'pack_dirstate()' is invoked
          via 'workingctx._checklookup()'.
      
        - invoke 'dirstate.write()' via releasing wlock at N+1 (or "not at N")
      
          'pack_dirstate()' via releasing wlock uses actual timestamp at
          runtime as "now", and it should be different from the "2000-01-01
          00:00" of "f".
      
      BTW, this patch also changes 'test-largefiles-misc.t', because adding
      'dirstate.write()' makes recent dirstate changes visible to external
      process.
      fe03f522dda9
  38. Jun 03, 2015
    • Matt Harbison's avatar
      scmutil: consistently return subrepos relative to ctx1 from itersubrepos() · c0995cd8ff6f
      Matt Harbison authored
      Previously, if a subrepo was added in ctx2 and then compared to another without
      it (ctx1), the subrepo for ctx2 was returned amongst all of the ctx1 based
      subrepos, since no subrepo exists in ctx1 to replace it in the 'subpaths' dict.
      The two callers of this, basectx.status() and cmdutil.diffordiffstat(), both
      compare the yielded subrepo against ctx2, and thus saw no changes when ctx2's
      subrepo was returned.  The tests here previously didn't mention 's/a' for the
      'p1()' case.
      
      This appears to have been a known issue, because some diffordiffstat() comments
      mention that the subpath disappeared, and "the best we can do is ignore it".  I
      originally ran into the issue with some custom convert code to flatten a tree of
      subrepos causing hg.putcommit() to abort, but this new behavior seems like the
      correct status and diff behavior regardless.  (The abort in convert isn't
      something users will see, because convert doesn't currently support subrepos in
      the official repo.)
      c0995cd8ff6f
Loading