Skip to content
Snippets Groups Projects
  1. 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
  2. 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
  3. 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
  4. 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
  5. Jun 06, 2017
  6. Jun 05, 2017
  7. May 25, 2017
  8. Apr 02, 2017
  9. Mar 20, 2017
  10. 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
  11. 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
  12. 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
  13. Oct 07, 2016
  14. Oct 08, 2016
  15. Sep 20, 2016
  16. 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
  17. Jul 27, 2016
  18. Jul 22, 2016
  19. Feb 29, 2016
  20. 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
  21. Jan 15, 2016
  22. Nov 25, 2015
  23. Oct 12, 2015
  24. 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
  25. 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
  26. 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
  27. Oct 07, 2015
  28. 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
  29. 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
  30. May 29, 2015
    • Gilles Moris's avatar
      summary: move the parents phase marker to commit line (issue4688) · 6084926366b9
      Gilles Moris authored
      The phase of the pending commit depends on the parent of the working directory
      and on the phases.newcommit configuration.
      First, this information rather depend on the commit line which describe the
      pending commit.
      Then, we only want to be advertised when the pending phase is going to be higher
      than the default new commit phase.
      
      So the format will change from
      
      $ hg summary
      parent: 2:ab91dfabc5ad
       foo
      parent: 3:24f1031ad244 tip
       bar
      branch: default
      commit: 1 modified, 1 unknown, 1 unresolved (merge)
      update: (current)
      phases: 1 secret (secret)
      
      to
      
      parent: 2:ab91dfabc5ad
       foo
      parent: 3:24f1031ad244 tip
       bar
      branch: default
      commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret)
      update: (current)
      phases: 1 secret
      6084926366b9
  31. May 27, 2015
    • Pierre-Yves David's avatar
      subrepo: detect issue3781 case earlier so it apply to bundle2 · 636b1f1b9f8d
      Pierre-Yves David authored
      We are doing some strange special casing of phase push when:
      
      - the source is a subrepo
      - the destination is publishing
      - some changeset are still draft on the destination
      
      In that case we do not push phases information (to publish the draft changesets)
      because it could break simple cycle of 'clone/pull/push' of subrepos. We have to
      detect this case earlier to have bundle2 respecting it.
      
      We change the test to check the behavior for both bundle1 and bundle2.
      636b1f1b9f8d
  32. May 10, 2015
    • Pierre-Yves David's avatar
      progress: get the extremely verbose output out of default debug · bd625cd4e5e7
      Pierre-Yves David authored
      When the progress extension is not enabled, each call to 'ui.progress' used to
      issue a debug message. This results is a very verbose output and often redundant
      in tests. Dropping it makes tests less volatile to factor they do not meant to
      test.
      
      We had to alter the sed trick in 'test-rename-merge2.t'. Sed is used to drop all
      output from a certain point and hidding the progress output remove its anchor.
      So we anchor on something else.
      bd625cd4e5e7
  33. May 14, 2015
    • Gilles Moris's avatar
      summary: add a phase line (draft, secret) to the output · 1ef96a3b8b89
      Gilles Moris authored
      The number of draft and secret changesets are currently not summarized.
      This is an important information because the number of drafts give some rough
      idea of the number of outgoing changesets in typical workflows, without needing
      to probe a remote repository. And a non-zero number of secrets means that
      those changeset will not be pushed.
      
      If the repository is "dirty" - some draft or secret changesets exists - then
      summary will display a line like:
      
      phases: X draft, Y secret (public)
      
      The phase in parenthesis corresponds to the highest phase of the parents of
      the working directory, i.e. the current phase.
      
      By default, the line is not printed if the repository is "clean" - all
      changesets are public - but if verbose is activated, it will display:
      
      phases: (public)
      
      On the other hand, nothing will be printed if quiet is in action.
      
      A few tests have been added in test-phases.t to cover the -v and -q cases.
      1ef96a3b8b89
  34. Apr 28, 2015
    • Matt Harbison's avatar
      subrepo: don't pass the outer repo's --rev or --branch to subrepo incoming() · b5513ee85dd8
      Matt Harbison authored
      When passing a --rev, 'hg incoming -S' previously suffered from the same output
      truncation or abort that was fixed for 'hg outgoing -S' in the previous patch,
      for the same reasons.
      
      Unlike push, subrepos are currently only pulled when the outer repo is updated,
      not when the outer repo is pulled.  That makes matching 'hg pull' behavior
      impossible.  Listing all incoming csets in the subrepo seems like the most
      useful behavior, and is consistent with 'hg outgoing -S'.
      b5513ee85dd8
    • Matt Harbison's avatar
      subrepo: don't pass the outer repo's --rev or --branch to subrepo outgoing() · 5135c2be6959
      Matt Harbison authored
      The previous behavior didn't reflect what would actually be pushed- push will
      ignore --rev and --branch in the subrepo and push everything.  Therefore,
      'push -r {rev}' would not list everything, unless {rev} was also the revision of
      the subrepo's tip.  Worse, if a hash was passed in, the command would abort
      because that hash would either not be in the outer repo or not in the subrepo.
      5135c2be6959
  35. Apr 25, 2015
    • Matt Harbison's avatar
      subrepo: don't write .hgsubstate lines with empty subrepo state (issue4622) · a99931201d1b
      Matt Harbison authored
      The '' that is used to represent the state of a not-yet-committed
      subrepo cannot be written to the file, because the code that parses
      the file splits on ' ' and expects two parts.
      
      Given that the .hgsubstate file is automatically rewritten on commit, it seems
      a little strange that the file is written out during a merge.
      a99931201d1b
  36. Mar 25, 2015
    • Katsunori FUJIWARA's avatar
      subrepo: add bailifchanged to centralize raising Abort if subrepo is dirty · 1ff35d76421c
      Katsunori FUJIWARA authored
      This patch also centralizes composing dirty reason message like
      "uncommitted changes in subrepository 'xxxx'".
      1ff35d76421c
    • Katsunori FUJIWARA's avatar
      subrepo: add dirtyreason to centralize composing dirty reason message · 76b0b0fed2e3
      Katsunori FUJIWARA authored
      This patch newly adds "dirtyreason()" to centralize composing dirty
      reason message like "uncommitted changes in subrepository 'xxxx'".
      
      There are 3 similar messages below, and this patch is a part of
      preparations for unifying them into (1), too.
      
        1. uncommitted changes in subrepository 'XXXX'
        2. uncommitted changes in subrepository XXXX
        3. uncommitted changes in subrepo XXXX
      
      This patch chooses adding new method "dirtyreason()" instead of making
      "dirty()" return "reason string", because:
      
        - some of existing "dirty()" implementation is too complicated to do
          so simply, and
      
        - ill-mannered 3rd party subrepo classes, of which "dirty()" doesn't
          return "reason string", cause meaningless message (even though it
          is rare case)
      76b0b0fed2e3
  37. Mar 19, 2015
    • Matt Harbison's avatar
      subrepo: add basic support to hgsubrepo for the files command · a8595176dd64
      Matt Harbison authored
      Paths into the subrepo are not yet supported.
      
      The need to use the workingctx in the subrepo will likely be used more in the
      future, with the proposed working directory revset symbol.  It is also needed
      with archive, if that code is to be reused to support 'extdiff -S'.
      Unfortunately, it doesn't seem possible to put the smarts in subrepo.subrepo(),
      as it breaks various status and diff tests.
      
      I opted not to pass the desired revision into the subrepo method explicitly,
      because the only ones that do pass an explicit revision are methods like status
      and diff, which actually operate on two contexts- the subrepo state and the
      explicitly passed revision.
      a8595176dd64
Loading