Skip to content
Snippets Groups Projects
  1. Jun 25, 2017
    • Katsunori FUJIWARA's avatar
      keyword: restore kwtemplater.match at the end of wrapped webcommands · 9062458febca
      Katsunori FUJIWARA authored
      Before this patch, kwweb_skip doesn't restore kwtemplater.match after
      wrapped webcommands. This suppresses keyword expansion at wrapped
      webcommands.
      
      Typical usecase of this issue is "file" webcommand after annotate,
      changeset, filediff or so on.
      
      To ensure kwtemplater.match=util.never while original webcommand
      running, this patch makes kwweb_skip yield values returned by it,
      because it returns generator object.
      9062458febca
    • Katsunori FUJIWARA's avatar
      keyword: restore kwtemplater.restrict at the end of wrapped patch.diff · 7f569ce30216
      Katsunori FUJIWARA authored
      Before this patch, kwdiff doesn't restore kwtemplater.restrict after
      invocation of wrapped patch.diff(). This suppresses keyword expansion
      at subsequent filelog.read().
      
      Typical usecase of this issue is "hg cat" after "hg diff" with command
      server. In this case, kwtemplater.restrict=True is kept in command
      server process even after "hg diff".
      
      To ensure kwtemplater.restrict=True while original patch.diff()
      running, this patch makes kwdiff() yield values returned by it,
      because it returns generator object.
      
      Strictly speaking, if filelog.read() is invoked before completely
      evaluating the result of previous patch.diff(), keyword expansion is
      still suppressed, because kwtemplater.restrict isn't restored yet.
      
      But this fixing should be reasonable enough, because patch.diff() is
      consumed immediately, AFAIK.
      7f569ce30216
  2. Jun 26, 2017
  3. Jun 23, 2017
  4. Jun 25, 2017
  5. Jun 22, 2017
  6. Jun 25, 2017
    • Jun Wu's avatar
      rebase: clean up rebasestate from active transaction · 2312e70cf78b
      Jun Wu authored
      Previously, rebase assumes the following pattern:
      
          rebase:
              with transaction as tr: # top-level
                  ...
              tr.__close__ writes rebasestate
              unlink('rebasestate')
      
      However it's possible that "rebase" was called inside a transaction:
      
          with transaction as tr1:
              rebase:
                  with transaction as tr2: # not top-level
                      ...
                  tr2.__close__ does not write rebasestate
                  unlink('rebasestate')
          tr1.__close__ writes rebasestate
      
      That leaves a rebasestate on disk incorrectly.
      
      This patch adds "removefilegenerator" to notify transaction code that the
      state file is no longer needed therefore fixes the issue.
      2312e70cf78b
    • Jun Wu's avatar
      test-rebase: add a test showing rebasestate left behind · be3584712b20
      Jun Wu authored
      The test demonstrates that .hg/rebasestate is left behind if "rebase" was
      called inside an existing transaction.
      be3584712b20
    • Matt Harbison's avatar
      identify: rename 'changed' keyword -> 'dirty' · a49ab7f5e7e7
      Matt Harbison authored
      I meant to do this before sending the initial templater support, but forgot.
      
      I'm quite surprised that 'dirty' doesn't occur in more user facing contexts, but
      there are a few, like the help for blackbox.  It also more obviously mirrors the
      '(clean)' state printed by the summary command.  I also didn't like that it was
      just one letter off from {changes} in the {latesttags} sub-keywords, which has a
      totally different meaning.
      a49ab7f5e7e7
  7. Jun 23, 2017
    • Katsunori FUJIWARA's avatar
      dispatch: remove unused _loaded · ef46d432e2e4
      Katsunori FUJIWARA authored
      Now, there is no user for dispatch._loaded.
      ef46d432e2e4
    • Katsunori FUJIWARA's avatar
      extensions: register functions always at loading extension (issue5601) · 45b0e9d05ee9
      Katsunori FUJIWARA authored
      Before this patch, functions defined in extensions are registered via
      extra loaders only in _dispatch(). Therefore, loading extensions in
      other code paths like below omits registration of functions.
      
        - WSGI service
        - operation across repositories (e.g. subrepo)
        - test-duplicateoptions.py, using extensions.loadall() directly
      
      To register functions always at loading new extension, this patch
      moves implementation for extra loading from dispatch._dispatch() to
      extensions.loadall().
      
      AFAIK, only commands module causes cyclic dependency between
      extensions module, but this patch imports all related modules just
      before extra loading in loadall(), in order to centralize them.
      
      This patch makes extensions.py depend on many other modules, even
      though extensions.py itself doesn't. It should be avoided if possible,
      but I don't have any better idea. Some other places like below aren't
      reasonable for extra loading, IMHO.
      
        - specific function in newly added module:
          existing callers of extensions.loadall() should invoke it, too
      
        - hg.repository() or so:
          no-repo commands aren't covered by this.
      
      BTW, this patch removes _loaded.add(name) on relocation, because
      dispatch._loaded is used only for extraloaders (for similar reason,
      "exts" variable is removed, too).
      45b0e9d05ee9
  8. Jun 25, 2017
    • Matt Harbison's avatar
      identify: add template support · 15a79ac823e8
      Matt Harbison authored
      This is based on a patch proposed last year by Mathias De Maré[1], with a few
      changes.
      
        - Tags and bookmarks are now formatted lists, for more flexible queries.
        - The templater is populated whether or not [-nibtB] is specified.  (Plain
          output is unchanged.)  This seems more consistent with other templated
          commands.
        - The 'id' property is a string, instead of a list.
        - The parents of 'wdir()' have their own list of attributes.
      
      I left 'id' as a string because it seems very useful for generating version
      info.  It's also a bit strange because the value and meaning changes depending
      on whether or not --debug is passed (short vs full hash), whether the revision
      is a merge or not (one hash or two, separated by a '+'), the working directory
      or not (node vs p1node), and local or not (remote defaults to tip, and never has
      '+').  The equivalent string built with {rev} seems much less useful, and I
      couldn't think of a reasonable name, so I left it out.
      
      The discussion seemed to be pointing towards having a list of nodes, with more
      than one entry for a merge.  It seems simpler to give the nodes a name, and use
      {node} for the actual commit probed, especially now that there is a virtual node
      for 'wdir()'.
      
      Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes.
      I'm not sure if the plan is to fill in all of the context attributes in these
      items, or if these nested items should simply be made {p1node} and {p1rev}.
      
      I used ':' as the tag separator for consistency with {tags} in the log
      templater.  Likewise, bookmarks are separated by a space for consistency with
      the corresponding log template.
      
      [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
      15a79ac823e8
  9. Jun 24, 2017
    • Gregory Szorc's avatar
      show: show all namespaces in "work" view · 0a507da7d8ea
      Gregory Szorc authored
      This commit addresses a number of deficiencies in `hg show work`'s
      output:
      
      * Failure to render tags (it just wasn't implemented)
      * Failure to render names associated with non-built-in namespaces
        (e.g. remotenames)
      * Color names were hardcoded instead of coming from the canonical
        source in the namespace
      
      This change has the intended effect of rendering tags and extra
      namespaces. It solves an immediate need at Mozilla of having
      names from a custom namespace printed, which is blocking us from
      switching from a custom `hg wip` revset/template combo to `hg show
      work`.
      
      Note that the order of branches and bookmarks changes. This is
      because bookmarks are registered before branches in namespaces.py.
      We may want to register them last, after tags and branches. Or we
      may want to added a weighted field to the namespace to control
      display order. Something to think about.
      
      I'm not a big fan of the complexity in the templating layer. There
      is a lot of code to basically filter out the special case of
      branch=='default' and tag=='tip'. Ideally, we would iterate over
      a data structure that had irrelevant/unwanted names pre-filtered.
      However, I wasn't sure how to best implement this. We probably
      want {namespaces} to emit everything (its current behavior). I
      was toying with the following:
      
      * {namespacesnondefaults} variation that filtered values
      * A filter function that operated on {namespaces} (I wasn't sure
        how to implement this since the filtering layer would see a
        "hybrid" instance as opposed to something that was definitely
        an iterable of namespaces.)
      * A namespaces(...) function where you could specify which values
        to return. I like this the most. But it really wants named
        arguments to control filtering and we only support named arguments
        on revsets, not templates.
      
      I figure perfect is the enemy of good and we can refine templating
      support for namespaces in the future. At least now we have a
      concrete example of a use case.
      0a507da7d8ea
    • Gregory Szorc's avatar
      tests: add more tests for names rendering in `hg show work` · 0b42c7ba46a6
      Gregory Szorc authored
      This demonstrates some missing features. This will also help
      verify that a subsequent change has the intended effect.
      0b42c7ba46a6
    • Gregory Szorc's avatar
      namespaces: record and expose whether namespace is built-in · 46fa46608ca5
      Gregory Szorc authored
      Currently, the templating layer tends to treat each namespace
      as a one-off, with explicit usage of {bookmarks}, {tags}, {branch},
      etc instead of using {namespaces}. It would be really useful if
      we could iterate over namespaces and operate on them generically.
      However, some consumers may wish to differentiate namespaces by
      whether they are built-in to core Mercurial or provided by extensions.
      Expected use cases include ignoring non-built-in namespaces or
      emitting a generic label for non-built-in namespaces.
      
      This commit introduces an attribute on namespace instances
      that says whether the namespace is "built-in" and then exposes
      this to the templating layer.
      
      As part of this, we implement a reusable extension for defining
      custom names on each changeset for testing. A second consumer
      will be introduced in a subsequent commit.
      46fa46608ca5
    • Gregory Szorc's avatar
      templatekw: expose color name in {namespaces} entries · de8e3681c402
      Gregory Szorc authored
      Templates make use of a "log.<namespace>" label. The <namespace> value
      here differs from the actual namespace name in that the namespace
      itself is plural but the label/color value is singular.
      
      Expose the color name to the templating layer so log.* labels
      can be emitted for {namespaces}.
      
      As part of this, we refactored the logic to eliminate a gnarly
      comprehension. We store color names in their own dict because the
      lookup can occur in tight loops and we shouldn't have to go to
      repo.names[ns] multiple times for every changeset.
      de8e3681c402
    • Gregory Szorc's avatar
      show: construct changeset templater during dispatch · 11f768258dcc
      Gregory Szorc authored
      Previously, we constructed a formatter from a specific template
      topic. Then from show() we reached into the internals of the
      formatter to resolve a template string to be used to construct
      a changeset templater.
      
      A downside to this approach was it limited us to having the
      entire template defined in a single entry in the map file. You
      couldn't reference other entries in the map file and this would
      lead to long templates and redundancy in the map file.
      
      This commit teaches @showview how to instantiate a changeset
      templater so we can construct a templater with full access to
      the map file. To prove it works, we've split "showwork" into
      components.
      11f768258dcc
    • Gregory Szorc's avatar
      cmdutil: use named arguments for changeset_templater.__init__ · 99c6c9fa9e6d
      Gregory Szorc authored
      This will make the API more extensible and easier to use.
      99c6c9fa9e6d
  10. Jun 23, 2017
  11. Jun 22, 2017
  12. Jun 23, 2017
  13. Jun 22, 2017
  14. Jun 16, 2017
    • Martin von Zweigbergk's avatar
      bundle: add a applybundle1() method · b82615afde65
      Martin von Zweigbergk authored
      This is one step towards removing a bunch of "if isinstance(gen,
      unbundle20)" by treating bundle1 and bundle2 more similarly.
      
      The name may sounds ironic for a method in the bundle2 module, but I
      didn't think it was worth it yet to create a new 'bundle' module that
      depends on the 'bundle2' module. Besides, we'll inline the method
      again later.
      b82615afde65
  15. Jun 22, 2017
  16. Jun 21, 2017
  17. Jun 24, 2017
    • Jun Wu's avatar
      test-rebase-conflicts: add a test case about turning obsstore on and off · 181ca34883e6
      Jun Wu authored
      Turning obsstore and allowunstable on, rebase will skip the
      "can't remove original changesets with unrebased descendants" check. Then
      rebase could be interrupted (merge conflict), and the user has a chance to
      turn off obsstore. If rebase continues, the current code may strip
      irrelevant commits (in the test case added, "C" got stripped unexpectedly).
      
      The test case reproduces issue5606. It will be fixed by the "multidest"
      rebase refactoring being reviewed. The test case itself is relatively
      separate from the rebase refactoring, therefore sent separately hoping to
      reduce the number of patches of the main rebase series.
      181ca34883e6
    • Augie Fackler's avatar
      merge with stable · 91ae09010950
      Augie Fackler authored
      91ae09010950
  18. Jun 15, 2017
    • Martin von Zweigbergk's avatar
      strip: include phases in bundle (BC) · 8e3021fd1a44
      Martin von Zweigbergk authored
      Before this patch, unbundling a stripped changeset would make it a
      draft (unless the parent was secret). This meant that one would lose
      phase information when stripping and unbundling secret changesets. The
      same thing was true for public changesets. While stripping public
      changesets is generally rare, it's done frequently by e.g. the
      narrowhg extension.
      
      We also include the phases in the temporary bundle, just in case
      stripping were to fail after that point, so the user can still restore
      the repo including phase information. Before this patch, the phases
      were left untouched during the bundling and unbundling of the
      temporary bundle. Only at the end of the transaction would
      phasecache.filterunknown() be called to remove phase roots that were
      no longer valid. We now need to call that also after the first
      stripping, i.e. before applying the temporary bundle. Otherwise
      unbundling the temporary bundle will cause a read of the phase cache
      which has stripped changesets in the cache and that fails.
      
      Like with obsmarkers, we unconditionally include the phases in the
      bundle when stripping (when using bundle2, such as when generaldelta
      is enabled). The reason for doing that for strip but not for bundle is
      that strip bundles are not meant to be shared outside the repo, so we
      don't care as much about compatibility.
      8e3021fd1a44
  19. Jun 22, 2017
    • Martin von Zweigbergk's avatar
      bundle: add config option to include phases · e8c8d81eb864
      Martin von Zweigbergk authored
      This adds an experimental.bundle-phases config option to include phase
      information in bundles. As with the recently added support for
      bundling obsmarkers, the support for bundling phases is hidden behind
      the config option until we decide to make a bundlespec v3 that
      includes phases (and obsmarkers and ...).
      
      We could perhaps use the listkeys format for this, but that's
      considered obsolete according to Pierre-Yves. Instead, we introduce a
      new "phase-heads" bundle part. The new part contains the phase heads
      among the set of bundled revisions. It does not include those in
      secret phase; any head in the bundle that is not mentioned in the
      phase-heads part is assumed to be secret. As a special case, an empty
      phase-heads part thus means that any changesets should be added in
      secret phase. (If we ever add a fourth phase, we'll include secret in
      the part and we'll add a version number.)
      
      For now, phases are only included by "hg bundle", and not by
      e.g. strip and rebase.
      e8c8d81eb864
  20. Jun 16, 2017
  21. Jun 22, 2017
  22. Jun 24, 2017
  23. Jun 23, 2017
Loading