Skip to content
Snippets Groups Projects
  1. Sep 22, 2014
  2. Sep 11, 2014
    • Katsunori FUJIWARA's avatar
      mq: examine "pushable" of already applied patch correctly · 4bbcee18
      Katsunori FUJIWARA authored
      Before this patch, "hg qselect" with --pop/--reapply may pop patches
      unexpectedly, even when all of patches applied before "qselect" are
      still pushable.
      
      Strictly speaking about the condition of this issue:
      
        - before "qselect"
          - there are N applied patches
          - the index of the guarded patch X in the series is less than N
      
        - after "qselect"
          - X is still guarded, and
          - all of applied patched are still pushable
      
      In the case above, "hg qselect" should keep current status, but it
      actually tries to pop patches because of X.
      
      The index in "the series" should be used to examine "pushable" of a
      patch by "mq.pushablek()", but the index in "applied patches" is used,
      and this may cause unexpected examination of guarded patch.
      
      To examine "pushable" of already applied patch correctly, this patch
      uses "mq.applied[i].name": "pushable" is the function introduced by
      the previous patch, and it returns "mq.pushable(mq.applied[i].name)[0]".
      4bbcee18
    • Katsunori FUJIWARA's avatar
      mq: pop correct patches when changing pushable-ness of already applied ones · c89379d4
      Katsunori FUJIWARA authored
      Before this patch, "hg qselect" with --pop/--reapply may pop incorrect
      patches, because the index in "applied patches" is used to pop patches
      by "mq.pop()", even though the index in "the series" should be used.
      
      For example, when the already applied patch becomes guarded and it
      follows the already guarded (= not yet applied) one, "hg qselect" is
      aborted, because it tries to pop to guarded one.
      
      This patch uses "mq.applied[i - 1].name" to pop to the patch, of which
      the index in the "applied ones" is "i - 1".
      c89379d4
    • Katsunori FUJIWARA's avatar
      mq: use "mq.applied[i].name" instead of "mq.appliedname(i)" for safety · ac31d876
      Katsunori FUJIWARA authored
      Before this patch, "hg qselect --reapply" is aborted when "--verbose"
      is specified, because "mq.appliedname()" returns "INDEX PATCHNAME"
      instead of "PATCHNAME" in such case and "mq.push" can't accept the
      former as the name of patch.
      
      This patch uses "mq.applied[i].name" instead of "mq.appliedname(i)" as
      the name of the patch to be pushed for safety.
      
      Now, there is no code path using "mq.appliedname()", and it should be
      removed to prevent developers from using it in the wrong way like this
      issue.
      ac31d876
    • Katsunori FUJIWARA's avatar
      mq: report correct numbers for changing "number of guarded, applied patches" · fd0f0b0d
      Katsunori FUJIWARA authored
      Before this patch, "hg qselect" may report incorrect numbers for
      "number of guarded, applied patches has changed", because it examines
      "pushable" of patches by the index not in "the series" but in "applied
      patches", even though "mq.pushable()" expects the former.
      
      To report correct numbers for changing "number of guarded, applied
      patches", this patch uses the name of applied patch to examine
      pushable-ness of it.
      
      This patch also changes the result of existing "hg qselect" tests,
      because they doesn't change pushable-ness of already applied patches.
      
      This patch assumes that "hg qselect" focuses on changing pushable-ness
      only of already applied patches, because:
      
        - the report message uses not "previous" (in the series) but
          "applied"
      
        - the logic to pop patches for --pop/--reapply examines
          pushable-ness only of already applied ones (in fact, there are
          some incorrect code paths)
      fd0f0b0d
  3. Sep 09, 2014
    • Katsunori FUJIWARA's avatar
      dispatch: check shell alias again after loading extensions (issue4355) · f98abe31
      Katsunori FUJIWARA authored
      Before this patch, the shell alias causes failure when it takes its
      specific (= unknown for "hg") options in the command line, because
      "_parse()" can't accept them.
      
      This is the regression introduced by 03d345da0579.
      
      It fixed the issue that ambiguity between shell aliases and commands
      defined by extensions was ignored. But it also caused that ambiguous
      shell alias is handled in "_parse()" even if it takes specific options
      in the command line.
      
      To avoid such failure, this patch checks shell alias again after
      loading extensions.
      
      All aliases and commands (including ones defined by extensions) are
      completely defined before the 2nd (= newly added in this patch)
      "_checkshellalias()" invocation, and "cmdutil.findcmd(strict=False)"
      can detect ambiguity between them correctly.
      
      For efficiency, this patch does:
      
        - omit the 2nd "_checkshellalias()" invocation if "[ui] strict= True"
      
          it causes "cmdutil.findcmd(strict=True)", of which result should
          be equal to one of the 1st invocation before adding aliases
      
        - avoid removing the 1st "_checkshellalias()" invocation
      
          it causes "cmdutil.findcmd(strict=True)" invocation preventing
          shell alias execution from loading extensions uselessly
      f98abe31
    • Katsunori FUJIWARA's avatar
      dispatch: make "_checkshellalias" reusable regardless of adding aliases · d821fff9
      Katsunori FUJIWARA authored
      To reduce changes in the subsequent patch fixing issue4355, this patch
      makes "_checkshellalias" reusable regardless of adding aliases.
      
      In this patch, alias definitions are added and restored, only when
      "precheck=True".
      d821fff9
  4. Sep 03, 2014
  5. Sep 02, 2014
  6. Sep 01, 2014
  7. Aug 30, 2014
    • Gregory Szorc's avatar
      help: only call doc() when it is callable · e284de13
      Gregory Szorc authored
      `hg help -k` on my machine was aborting because the hg-prompt extension
      was inserting a string and not a function into help.helptable and help
      was blindly calling it.
      
      This patch changes keyword searching to be more robust against
      unexpected types.
      e284de13
  8. Sep 01, 2014
  9. Aug 31, 2014
  10. Aug 30, 2014
  11. Aug 31, 2014
    • Mike Hommey's avatar
      repoview: fix typo in repoview.changelog · e1d5fcab
      Mike Hommey authored
      Incidentally, this avoids the changelog cache being invalidated each time
      it's accessed on a repoview.
      
      On a filtering experiment on a repository the size of mozilla-central,
      this makes a significant difference:
      
      Before, running hg log -l 10 --time with about 8k changesets filtered out:
      time: real 1.490 secs (user 1.450+0.000 sys 0.040+0.000)
      
      After:
      time: real 0.540 secs (user 0.530+0.000 sys 0.010+0.000)
      e1d5fcab
  12. Aug 19, 2014
  13. Aug 30, 2014
  14. Aug 27, 2014
    • Katsunori FUJIWARA's avatar
      import: show the warning message for failure of merging · 0c838e74
      Katsunori FUJIWARA authored
      Before this patch, no message is shown for failure of merging at "hg
      import".
      
      In such case, merging patch is imported as a normal revision silently,
      and it may confuse users.
      
      For simplicity, this patch recommends just using "--exact", even
      though importing the merging patch itself is possible without it if:
      
        - the hash of the 1st parent in the patch is equal to one of the
          patch imported just before (or the parent of the working
          directory, for the 1st patch of the series), and
      
        - the hash of the 2nd parent in the patch is known in the local
          repository
      0c838e74
    • Mads Kiilerich's avatar
      graft: fix collision detection with origin revisions that are missing · 9472284d
      Mads Kiilerich authored
      When grafting something with a matching origin, it would normally be skipped:
        skipping already grafted revision 123 (23 also has origin 12)
      
      But after stripping a graft origin, graft could fail with a reference to the
      origin that no longer exists:
        abort: unknown revision '5c095ad7e90f871700f02dd1fa5012cb4498a2d4'!
      
      Instead, detect that the origin is unknown and skip it anyway, like:
        skipping already grafted revision 8 (2 also has unknown origin 5c095ad7e90f871700f02dd1fa5012cb4498a2d4)
      9472284d
  15. Aug 23, 2014
  16. Aug 25, 2014
  17. Aug 15, 2014
  18. Aug 14, 2014
  19. Aug 13, 2014
Loading