Skip to content
Snippets Groups Projects
  1. Mar 09, 2014
    • Katsunori FUJIWARA's avatar
      templater: make strings in template expressions be "string-escape"-ed correctly · 5ab28a2e
      Katsunori FUJIWARA authored
      Changeset 64b4f0cd7336 (released with 2.8.1) fixed "recursively
      evaluate string literals as templates" problem (issue4102) by moving
      the location of "string-escape"-ing from "tokenizer()" to
      "compiletemplate()".
      
      But some parts in template expressions below are not processed by
      "compiletemplate()", and it may cause unexpected result.
      
        - 'expr' of 'if(expr, then, else)'
        - 'expr's of 'ifeq(expr, expr, then, else)'
        - 'sep' of 'join(list, sep)'
        - 'text' and 'style' of 'rstdoc(text, style)'
        - 'text' and 'chars' of 'strip(text, chars)'
        - 'pat' and 'repl' of 'sub(pat, repl, expr)'
      
      For example, '\n' of "{join(extras, '\n')}" is not "string-escape"-ed
      and treated as a literal '\n'. This breaks "Display the contents of
      the 'extra' field, one per line" example in "hg help templates".
      
      Just "string-escape"-ing on each parts above may not work correctly,
      because inside expression of nested ones already applies
      "string-escape" on string literals. For example:
      
        - "{join(files, '\n')}" doesn't return "string-escape"-ed string, but
        - "{join(files, if(branch, '\n', '\n'))}" does
      
      To fix this problem, this patch does:
      
        - introduce "rawstring" token and "runrawstring" method to handle
          strings not to be "string-escape"-ed correctly, and
      
        - make "runstring" method return "string-escape"-ed string, and
          delay "string-escape"-ing until evaluation
      
      This patch invokes "compiletemplate()" with "strtoken=exp[0]" in
      "gettemplate()", because "exp[1]" is not yet evaluated. This code path
      is tested via mapping ("expr % '{template}'").
      
      In the other hand, this patch invokes it with "strtoken='rawstring'"
      in "_evalifliteral()", because "t" is the result of "arg" evaluation
      and it should be "string-escape"-ed if "arg" is "string" expression.
      
      This patch doesn't test "string-escape"-ing on 'expr' of 'if(expr,
      then, else)', because it doesn't affect the result.
      5ab28a2e
    • Katsunori FUJIWARA's avatar
      templater: apply "stringify()" on sub expression to get string correctly · a54c0d83
      Katsunori FUJIWARA authored
      Templating syntax allows nested expression to be specified as parts
      below, but they are evaluated as a generator and don't work correctly.
      
        - 'sep' of 'join(list, sep)'
        - 'text' and 'chars' of 'strip(text, chars)'
      
      In the former case, 'sep' returns expected string only for the first
      separation, and empty one for the second or later, because the
      generator has only one element.
      
      In the latter case, templating is aborted by exception, because the
      generator doesn't have 'strip()' method (as 'text') and can't be
      passed as the argument to 'str.strip()' (as 'chars').
      
      This patch applies "stringify()" on these sub expression to get string
      correctly.
      a54c0d83
    • Katsunori FUJIWARA's avatar
      templater: avoid recursive evaluation of string literals completely · 7e627fe6
      Katsunori FUJIWARA authored
      Changeset 3d8bfe2ecf6d (released with 2.8.1) fixed "recursively
      evaluate string literals as templates" problem (issue4103) by
      introducing "_evalifliteral()".
      
      But some parts in template expressions below are still processed by
      the combination of "compiletemplate()" and "runtemplate()", and may
      cause same problem unexpectedly.
      
        - 'init' and 'hang' of 'fill(text, width, init, hang)'
        - 'expr' of 'sub(pat, repl, expr)'
        - 'label' of 'label(label, expr)'
      
      This patch processes them by "_evalifliteral()" instead of the
      combination of "compiletemplate()" and "runtemplate()" to avoid
      recursive evaluation of string literals completely.
      7e627fe6
  2. Mar 03, 2014
  3. Mar 01, 2014
  4. Feb 26, 2014
  5. Feb 27, 2014
    • Pierre-Yves David's avatar
      merge: infer the "other" changeset when falling back to v1 format · 303cbfe3
      Pierre-Yves David authored
      When we have to fallback to the old version of the file, we infer the
      "other" from current working directory parent. The same way it is currently done
      in the resolve command. This is know to have shortcoming… but we cannot do
      better from the data contained in the old file format. This is actually the
      motivation to add this new file format.
      303cbfe3
  6. Feb 26, 2014
    • Pierre-Yves David's avatar
      merge: record the "other" node in merge state · 02c60e38
      Pierre-Yves David authored
      We need to record the merge we were merging with. This solve multiple
      bug with resolve when dropping the second parent after a merge. This
      happen a lot when doing special merge (overriding the ancestor).
      Backout, shelve, rebase, etc. can takes advantage of it.
      
      This changeset just add the information in the merge state. We'll use it in the
      resolve process in a later changeset.
      02c60e38
    • Pierre-Yves David's avatar
      merge: introduce new format for the state file · 2b7d54e9
      Pierre-Yves David authored
      This new format will allow us to address common bugs while doing special merge
      (graft, backout, rebase…) and record user choice during conflict resolution.
      
      The format is open so we can add more record for future usage.
      
      This file still store hexified version of node to help human willing to debug
      it by hand. The overhead or oversize are not expected be an issue.
      
      The old format is still used. It will be written to disk along side the newer
      format. And at parse time we detect if the data from old version of the
      mergestate are different from the one in the new version file. If its the same,
      both have most likely be written at the same time and you can trust the extra
      data from the new file. If it differs, the old file have been written by an
      older version of mercurial that did not knew about the new file. In that case we
      use the content of the old file.
      2b7d54e9
  7. Feb 27, 2014
  8. Feb 26, 2014
  9. Feb 27, 2014
  10. Feb 25, 2014
    • Piotr Klecha's avatar
      pull: close peer repo on completion (issue2491) (issue2797) · 7f865a94
      Piotr Klecha authored
      When pulling changes from a compressed bundle Mercurial first uncompresses it
      to a temporary file in .hg directory. This file will not be deleted unless
      the bundlerepo (other) is explicitly closed.
      
      This is similar to cleanup that occurs after incoming.
      7f865a94
  11. Feb 26, 2014
    • Paul Boddie's avatar
      hgweb: ensure isdirectory is None for repositories, replacing any True value · 3d77e567
      Paul Boddie authored
      Until now, repositories did not provide any value for isdirectory in rows
      produced for the index output, and thus isdirectory was generally evaluated as
      None for each index entry representing a repository.
      
      However, directories (visible when viewed with the descend and collapse
      settings enabled) did provide a value of True and this value appeared to
      persist in subsequent rows processed by the templater, causing isdirectory
      tests in templates to produce incorrect results for index entries appearing
      after directories.
      
      This patch asserts the None value for repositories, thus erasing any such
      persistent True values.
      3d77e567
  12. Feb 25, 2014
  13. Feb 23, 2014
  14. Feb 16, 2014
  15. Feb 19, 2014
  16. Feb 15, 2014
  17. Feb 13, 2014
  18. Feb 10, 2014
  19. Feb 09, 2014
    • Mads Kiilerich's avatar
      merge: don't overwrite file untracked after remove, abort with 'untracked files' · e4d7cbc9
      Mads Kiilerich authored
      Merge could overwrite untracked files and cause data loss.
      
      Instead we now handle the 'local side removed file and has untracked file
      instead' case as the 'other side added file that local has untracked' case:
      
        FILE: untracked file exists
        abort: untracked files in working directory differ from files in requested revision
      
      It could perhaps make sense to create .orig files when overwriting, either
      instead of aborting or when overwriting anyway because of force ... but for now
      we stay consistent with similar cases.
      e4d7cbc9
  20. Feb 05, 2014
  21. Feb 03, 2014
  22. Feb 01, 2014
  23. Jan 31, 2014
  24. Jan 30, 2014
  25. Jan 22, 2014
Loading