Skip to content
Snippets Groups Projects
  1. Aug 15, 2018
  2. Aug 17, 2018
  3. Aug 15, 2018
    • Boris Feld's avatar
      sparse-revlog: fix delta validity computation · 3730b779ed5b
      Boris Feld authored
      When considering the validity of a delta with sparse-revlog, we check the size
      of the largest read. To do so, we use some regular logic with the extra delta
      information. Some of this logic was not handling this extra delta properly,
      confusing it with "nullrev". This confusion with nullrev lead to wrong results
      for this computation but preventing a crash.
      
      Changeset 781b2720d2ac on default revealed this error, crashing. This
      changeset fixes the logic on stable so that the computation is correct (and
      the crash is averted).
      
      The fix is made on stable as this will impact 4.7 clients interacting with
      sparse-revlog repositories (eg: created by later version).
      3730b779ed5b
  4. Aug 17, 2018
  5. Aug 16, 2018
  6. Jul 25, 2018
  7. Aug 16, 2018
    • Kyle Lippincott's avatar
      overlayworkingctx: fix exception in metadata-only inmemory merges (issue5960) · 95bd19f60957
      Kyle Lippincott authored
      If there was a metadata-only mutation, such as +x or -x on a file, we would
      create a cache entry with None for data, and this would cause problems later on
      when some code tried to run fctx.data() or similar, and was expecting a string.
      
      My original fix for this involved passing data=self._wrappedctx[path].data() in
      setflags(), but this version seems slightly better - this way, if we ever call
      write() and then call setflags(), we don't destroy the data that we wrote that's
      in the cache. I haven't verified that other fields aren't destroyed, such as
      date or flags :)
      
      Differential Revision: https://phab.mercurial-scm.org/D4287
      95bd19f60957
  8. Aug 14, 2018
  9. Aug 15, 2018
    • Katsunori FUJIWARA's avatar
      filemerge: add config knob to check capabilities of internal merge tools · cded904f7acc
      Katsunori FUJIWARA authored
      For historical reason, Mercurial assumes capabilities of internal
      merge tools as below while examining rules to decide merge tool,
      regardless of actual capabilities of them.
      
          =============== ====== ========
          specified via   binary symlinks
          =============== ====== ========
          --tool          o      o
          HGMERGE         o      o
          merge-patterns  o (*)  x (*)
          ui.merge        x (*)  x (*)
          =============== ====== ========
      
      This causes:
      
        - unintentional internal merge tool is chosen for binary files via
          merge-patterns section of configuration file
      
        - explicit configuration of internal merge tool for symlinks is
          ignored unintentionally
      
      But on the other hand, simple "check capability strictly" might break
      backward compatibility (e.g. existing merge automations), because it
      changes the result of merge tool selection.
      
      Therefore, this patch adds config knob "merge.strict-capability-check"
      to control whether capabilities of internal merge tools should be
      checked strictly or not.
      
      If this configuration is true, capabilities of internal merge tools
      are checked strictly in (*) cases above.
      cded904f7acc
    • Katsunori FUJIWARA's avatar
      filemerge: show warning if chosen tool has no binary files capability · 6618634e3325
      Katsunori FUJIWARA authored
      While matching patterns in "merge-patterns" configuration, Mercurial
      silently assumes that all merge tools have binary files
      capability. This implementation comes from 5af5f0f9d724 (or Mercurial
      1.0).
      
      At failure of merging binary files with incorrect internal merge tool,
      there is no hint about this silent ignorance of binary files
      capability.
      
      This patch shows warning message, if chosen internal merge tool has no
      binary files capability. This will help users to investigate why a
      binary file isn't merged as expected.
      6618634e3325
  10. Aug 14, 2018
    • Katsunori FUJIWARA's avatar
      filemerge: add the function to examine a capability of a internal tool · 4d7b11877dd0
      Katsunori FUJIWARA authored
      For "symlink" and "binary" capabilities, _toolbool() can not examine
      these of internal merge tools strictly, because it examines only
      configurations in "merge-tools" section.
      
      Users can configure them explicitly as below for example, but this is
      not ordinary usage and not convenient:
      
        [merge-tools]
        :other.symlink = true
        :other.binary = true
      
      This patch adds hascapability() internal function, which can examine
      actual capabilities of a internal merge tool strictly.
      
      At this patch, hascapability() is still used with "strict=False".
      Subsequent patches use it with "strict=True".
      4d7b11877dd0
    • Katsunori FUJIWARA's avatar
      filemerge: set actual capabilities of internal merge tools · 5d3b58472660
      Katsunori FUJIWARA authored
      This information is used to detect actual capabilities of internal
      merge tools by subsequent patches.
      
      For convenience, this patch assumes that merge tools typed as
      "nomerge" have both binary files and symlinks capabilities.
      5d3b58472660
    • Katsunori FUJIWARA's avatar
      help: describe more detail about capabilities while deciding merge tool · 7c6044634957
      Katsunori FUJIWARA authored
      "hg help merge-tools" describes as below:
      
          (internal merge tools) will by default not handle symlinks or
          binary files.
      
      But in some cases, Mercurial assumes that internal merge tools have
      one or both of these capabilities.
      
      "hg help merge-tools" also describes as below, for matching patterns in
      merge-patterns configuration section. But this is not sufficient.
      
          Here, binary capabilities of the merge tool are not considered.
      
      This patch describes more detail about capabilities while deciding
      merge tool.
      7c6044634957
  11. Aug 16, 2018
  12. Aug 15, 2018
  13. Aug 13, 2018
  14. Aug 16, 2018
  15. Jul 07, 2018
    • Yuya Nishihara's avatar
      commit: try hard to reuse p1 manifest if nothing changed · 46da52f4b820
      Yuya Nishihara authored
      This is all for commit reproducibility on "hg convert".
      
      With this change, p1 manifest is reused if ctx.files() *to be committed* is
      empty, and if new manifest entry is identical to p1. This is important
      property for "hg convert" since memctx.files() built from a convert source
      may be either a) more narrowed thanks to a committed ctx.files() which
      provides more accurate status, or b) containing redundant files because of
      sloppy filtering on e.g. octopus merge.
      46da52f4b820
  16. Aug 12, 2018
    • Yuya Nishihara's avatar
      merge: add tests for commit with no content change · f0c2653ca706
      Yuya Nishihara authored
      It isn't easy to say when to reuse the p1 manifest. Basically, that's only
      when wctx.files() is empty, but we need to know that wctx.files() is not
      the same as repo['.'].files() after the commit.
      
      This patch adds several examples of commits with empty ctx/wctx.files().
      I don't think this is exhaustive, but it contains at least one failure
      mode in which a converted repo result in a different hash.
      
      I also note that the manifest revlog does NOT follow the DAG shape of the
      changelog since p1 manifest is reused if wctx.files() is empty even at merge.
      I don't know whether it is intentional or not, but it's the behavior since
      2011, 301725c3df9a "localrepo: reuse parent manifest in commitctx if no files
      have changed."
      f0c2653ca706
  17. Jul 07, 2018
Loading