Skip to content
Snippets Groups Projects
  1. Sep 12, 2014
  2. Aug 24, 2014
    • Jordi Gutiérrez Hermoso's avatar
      color: document that changeset phases have labels · f8e2aebbb24c
      Jordi Gutiérrez Hermoso authored
      It's very useful to be able to colourise csets according to their
      phases. There was no indication anywhere in the docs that this is
      possible.
      
      We use e.g. `changeset.secret = ` instead of `changeset.secret
      ='none'`, because otherwise this is a BC: it would nullify the effects
      given to log.changeset label that usually surrounds the
      changeset.{phase} labels. Specifying the label without any effect
      instead of 'none' is a true no-op change and purely documentation.
      f8e2aebbb24c
  3. Sep 19, 2014
    • Matt Mackall's avatar
      color: change the debug output format · 964dd1c491ca
      Matt Mackall authored
      Before, the format was
      
       label(labeled text)  # single label
       [label1 label2](labeled text) # multiple
      
      Now, it's
      
       [labels|labeled text]
      
      ..which should make things a bit more clear.
      964dd1c491ca
  4. Aug 24, 2014
    • Jordi Gutiérrez Hermoso's avatar
      color: enable debug option to show labels · 1c4ae0f6a30f
      Jordi Gutiérrez Hermoso authored
      This is a debug option for showing labels. This can be helpful for
      knowing which labels are available for colouring or to see the output
      when defining your own templates. A couple of tests are included.
      1c4ae0f6a30f
    • Jordi Gutiérrez Hermoso's avatar
      color: document that labels are used for colorizing text · fbd67cf34799
      Jordi Gutiérrez Hermoso authored
      It is a deeply hidden secret that it's possible to colorise so many
      things with so many different labels. This is an attempt to document
      this. The text is a bit long, but it seems as short as can be while
      documenting everything. Perhaps it should be hidden under a --verbose
      option.
      fbd67cf34799
  5. Aug 27, 2014
  6. Aug 20, 2014
  7. Sep 17, 2014
  8. Sep 07, 2014
    • Gregory Szorc's avatar
      revsetbenchmarks: add an additional roots() benchmark · a476ee0b8e79
      Gregory Szorc authored
      The existing roots(x - y) revset only considered the most recent 100
      revisions. This was a good start. But expanding it to the full history
      of the repository can dramatically increase execution time and thus
      constitutes a useful benchmark.
      a476ee0b8e79
  9. Sep 16, 2014
  10. Sep 11, 2014
    • Katsunori FUJIWARA's avatar
      mq: examine "pushable" of already applied patch correctly · 4bbcee186fc6
      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]".
      4bbcee186fc6
    • Katsunori FUJIWARA's avatar
      mq: pop correct patches when changing pushable-ness of already applied ones · c89379d47e95
      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".
      c89379d47e95
    • Katsunori FUJIWARA's avatar
      mq: use "mq.applied[i].name" instead of "mq.appliedname(i)" for safety · ac31d87608d6
      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.
      ac31d87608d6
    • Katsunori FUJIWARA's avatar
      mq: report correct numbers for changing "number of guarded, applied patches" · fd0f0b0d316d
      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)
      fd0f0b0d316d
  11. Aug 29, 2014
  12. Sep 12, 2014
    • Durham Goode's avatar
      revset: lower weight for _intlist function · 186fd06283b4
      Durham Goode authored
      The histedit command uses a revset like:
      
      (_intlist('1234\x001235')) and merge()
      
      Previously the optimizer gave a weight of 1.5 to the _intlist side (1 for the
      function, 0.5 for the string) which caused it to process the merge() side first.
      This caused it to evaluate merge against every commit in the repo, which took
      2.5 seconds on a large repo.
      
      I changed the weight of _intlist to 0, since it's a trivial calculation, which
      makes it process intlist first, which makes merge apply only to the revs in the
      list. Which makes the revset take 0.15 seconds now. Cutting off 2.4 seconds off
      our histedit performance.
      
      >From the revset benchmark:
      revset #25: (_intlist('20000\x0020001')) and merge()
      0) obsolete feature not enabled but 54243 markers found!
      ! wall 0.036767 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
      1) obsolete feature not enabled but 54243 markers found!
      ! wall 0.000198 comb 0.000000 user 0.000000 sys 0.000000 (best of 9084)
      186fd06283b4
    • Durham Goode's avatar
      revset: make parents() O(number of parents) · 95af98616aa7
      Durham Goode authored
      Strip executes a revset like this:
      
      max(parents(_intlist('1234\x001235')) - _intlist('1234\x001235'))
      
      Previously the parents() revset would do 'subset & parents' which iterates over
      each item in the subset and checks if it's in parents.  subset is usually the
      entire repo (a spanset) so this takes a while.
      
      Reversing the parameters to be 'parents & subset' means the operation becomes
      O(number of parents) instead of O(size of repo). It also means the result gets
      evaluated immediately (since parents isn't a lazy set), but I think this is a
      win in most scenarios.
      
      This shaves 0.3 seconds off strip (amend/histedit/rebase/etc) for large repositories.
      
      revset #0: parents(20000)
      0) obsolete feature not enabled but 54243 markers found!
      ! wall 0.006256 comb 0.010000 user 0.010000 sys 0.000000 (best of 289)
      1) obsolete feature not enabled but 54243 markers found!
      ! wall 0.000391 comb 0.000000 user 0.000000 sys 0.000000 (best of 4323)
      95af98616aa7
    • Durham Goode's avatar
      revset: make descendants() lazier · da05fe01170b
      Durham Goode authored
      Previously descendants() would force the provided subset to become a set.  In
      the case of revsets like '(%ld::) - (%ld)' (as used by histedit) this would
      force the '- (%ld)' set to be evaluated, which produced a set containing every
      commit in the repo (except %ld). This takes 0.6s on large repos.
      
      This changes descendants to trust the subset to implement __contains__
      efficiently, which improves the above revset to 0.16s. Shaving 0.4 seconds off
      of histedit.
      
      revset #27: (20000::) - (20000)
      0) obsolete feature not enabled but 54243 markers found!
      ! wall 0.023640 comb 0.020000 user 0.020000 sys 0.000000 (best of 100)
      1) obsolete feature not enabled but 54243 markers found!
      ! wall 0.019589 comb 0.020000 user 0.020000 sys 0.000000 (best of 100)
      
      This commit removes the final revset related perf hotspot from histedit.
      Combined with the previous two patches, they shave a little over 3 seconds off
      histedit on large repos.
      da05fe01170b
  13. Sep 16, 2014
  14. Sep 15, 2014
  15. Aug 31, 2014
  16. May 14, 2014
  17. Aug 31, 2014
  18. May 30, 2014
  19. Aug 31, 2014
  20. May 14, 2014
  21. Aug 31, 2014
  22. Aug 28, 2014
    • Katsunori FUJIWARA's avatar
      templater: add "diff" template function · 40ce05b50148
      Katsunori FUJIWARA authored
      "diff" allows to embed changes in the target revision into template
      output, even if the command itself doesn't take "--patch" option
      
      Combination of "[committemplate]" configuration and "diff" template
      function can achieve the feature like issue231 ("option to have diff
      displayed in commit editor buffer")
      
          http://bz.selenic.com/show_bug.cgi?id=231
      
      For example, templating below can be used to add each "diff" output
      lines "HG: " prefix::
      
            {splitlines(diff) % 'HG: {line}\n'}
      
      This patch implements "diff" not as "a template keyword" but as "a
      template function" to take include/exclude patterns at runtime.
      
      It allows to specify target files of command (by -I/-X command line
      options) and "diff" separately.
      40ce05b50148
  23. Sep 16, 2014
  24. Mar 16, 2014
  25. Sep 12, 2014
  26. Sep 15, 2014
  27. Sep 12, 2014
  28. Sep 15, 2014
Loading