Skip to content
Snippets Groups Projects
  1. Feb 01, 2015
    • Katsunori FUJIWARA's avatar
      templatekw: re-add showtags() to list tags keyword up in online help · 0870bb93
      Katsunori FUJIWARA authored
      Changeset d69a7fc68ad5 removed "showtags()" definition for "tags"
      template keyword from "templatekw.py", because "namespaces" puts a
      helper function for it into template keyword map automatically. This
      works correctly from the point of view of templating functionality.
      
      But on the other hand, it removed "tags" template keyword from "hg
      help templates" unexpectedly, because online help text is built before
      "namespaces" puts a helper function for "tags" into template keyword
      map.
      
      This patch is a kind of backing d69a7fc68ad5 out, but this implements
      "showtags()" with newly introduced "shownames()" instead of originally
      used "showlist()".
      0870bb93
  2. Jan 31, 2015
    • Matt Harbison's avatar
      largefiles: don't interfere with logging normal files · 34493912
      Matt Harbison authored
      The previous code was adding standin files to the matcher's file list when
      neither the standin file nor the original existed in the context.  Somehow, this
      was confusing the logging code into behaving differently from when the extension
      wasn't loaded.
      
      It seems that this was an attempt to support naming a directory that only
      contains largefiles, as a test fails if the else clause is dropped entirely.
      Therefore, only append the "standin" if it is a directory.  This was found by
      running the test suite with --config extensions.largefiles=.
      
      The first added test used to log an additional cset that wasn't logged normally.
      The only relation it had to file 'a' is that 'a' was the source of a move, but
      it isn't clear why having '.hglf/a' in the list causes this change:
      
          @@ -47,6 +47,11 @@
      
           Make sure largefiles doesn't interfere with logging a regular file
             $ hg log a --config extensions.largefiles=
          +  changeset:   3:2ca5ba701980
          +  user:        test
          +  date:        Thu Jan 01 00:00:04 1970 +0000
          +  summary:     d
          +
             changeset:   0:9161b9aeaf16
             user:        test
             date:        Thu Jan 01 00:00:01 1970 +0000
      
      The second added test used to complain about a file not being in the parent
      revision:
      
          @@ -1638,10 +1643,8 @@
      
           Ensure that largefiles doesn't intefere with following a normal file
             $ hg  --config extensions.largefiles= log -f d -T '{desc}' -G
          -  @  c
          -  |
          -  o  a
          -
          +  abort: cannot follow file not in parent revision: ".hglf/d"
          +  [255]
             $ hg log -f d/a -T '{desc}' -G
             @  c
             |
      
      Note that there is still something fishy with the largefiles code, because when
      using a glob pattern like this:
      
          $ hg log 'glob:sub/*'
      
      the pattern list would contain '.hglf/glob:sub/*'.  None of the tests show this
      (this test lives in test-largefiles.t at 1349), it was just something that I
      noticed when the code was loaded up with print statements.
      34493912
  3. Jan 30, 2015
    • Pierre-Yves David's avatar
      discovery: properly exclude locally known but filtered heads · 3b7088a5
      Pierre-Yves David authored
      The conditional was a bit too narrow and produced buggy result when a node was
      present in both common and heads (because it pleased the discovery) and it was
      locally known but filtered.
      
      This resulted in buggy getbundle request and server side crash.
      3b7088a5
    • Pierre-Yves David's avatar
      test: make test-extdiff resilient to /usr/bin/echo · e484546a
      Pierre-Yves David authored
      My test machine has 'echo' in '/usb/bin/echo', #dontaskmewhy.
      e484546a
    • Pierre-Yves David's avatar
      obsstore: make the invalid markers check wrap-able · 18d43114
      Pierre-Yves David authored
      Some evolve user ignored the invalid markers for about two years and still have
      some of them in some repository. This lead to plain abort whenever mercurial try
      to open such repo. We need reinstall some way to clean this up in the evolve
      extension. For this purpose, we need the checker code wrap-able independently.
      
      This is scheduled for stable as this issue is blocking some evolve user.
      18d43114
    • Mads Kiilerich's avatar
      convert: replace revision references in messages if they are >= short hashes · c408bf3b
      Mads Kiilerich authored
      Convert will try to find references to revisions in commit messages and replace
      them with references to the converted revision. It will take any string that
      looks like a hash (and thus also decimal numbers) and look it up in the source
      repo. If it finds anything, it will use that in the commit message instead.
      
      It would do that for all hex digit sequences of 6 to 40 characters. That was
      usually no problem for small repos where it was unlikely that there would be a
      matching 6 'digit' hash prefix. It was also no problem on repos with less than
      100000 changesets where numbers with 6 or more digits not would match any
      revision number. With more than 100000 revisions random numbers in commit
      messages would be replaced with a "random" hash. For example, 'handle 100000
      requests' would be changed to to 'handle 9117c6 requests'. Convert could thus
      not really be used on real repositories with more than 100000 changesets.
      
      The default hash length shown by Mercurial is 12 'digits'. It is unexpected and
      unwanted that convert by default tries to replace revision references that use
      less than that amount of 'digits'.
      
      To fix this, don't match strings that are less than the default hash size of 12
      characters.
      c408bf3b
  4. Jan 29, 2015
    • Katsunori FUJIWARA's avatar
      merge: mark .hgsubstate as possibly dirty before submerge for consistency · 6becb9db
      Katsunori FUJIWARA authored
      Before this patch, failure of updating subrepos may cause inconsistent
      ".hgsubstate". For example:
      
        1. dirstate entry for ".hgsubstate" of the parent repo is filled
           with valid size/date (via "hg state" or so)
      
        2. "hg update" is invoked at the parent repo
      
        3. ".hgsubstate" of the parent repo is updated on the filesystem as
           a part of "g"(et) action in "merge.applyupdates"
      
        4. it is assumed that size/date of ".hgsubstate" on the filesystem
           aren't changed from ones at (1)
      
           this is not so difficult condition, because just changing hash
           ids (every ids are same in length) in ".hgsubstate" doesn't
           change the file size of it
      
        5. "subrepo.submerge()" is invoked to update subrepos
      
        6. failure of updating in one of subrepos raises exception
           (e.g. "untracked file differs")
      
        7. "hg update" is aborted without updating dirstate of the parent repo
      
           dirstate entry for ".hgsubstate" still holds size/date at (1)
      
      Then, ".hgsubstate" of the parent repo is treated as "CLEAN"
      unexpectedly, because updating ".hgsubstate" at (3) doesn't change
      size/date of it on the filesystem: see assumption at (4).
      
      This inconsistent ".hgsubstate" status causes unexpected behavior, for
      example:
      
        - "hg revert" forgets to revert ".hgsubstate"
      
        - "hg update" misunderstands that (not yet updated) subrepos diverge
          (then, it shows the prompt to confirm user's decision)
      
      To avoid inconsistent ".hgsubstate" status above, this patch marks
      ".hgsubstate" as possibly dirty before "submerge" invocation.
      "normallookup"-ed (= dirty) dirstate should be written out, even if
      processing is aborted by failure.
      
      This patch marks ".hgsubstate" as possibly dirty before "submerge",
      also when it is removed or merged while merging, for safety. This
      should prevent Mercurial from misunderstanding inconsistent
      ".hgsubstate" as clean.
      
      To satisfy conditions at (1) and (4) above, this patch uses "hg status
      --config debug.dirstate.delaywrite=2" (to fill valid size/date into
      dirstate) and "touch" (to fix date of the file).
      6becb9db
  5. Jan 27, 2015
    • Pierre-Yves David's avatar
      rebase: ensure rebase revision remains visible (issue4504) · 8a544fb6
      Pierre-Yves David authored
      Before this changeset rebase was getting very confused if any revision in the
      rebase set became hidden. This was fairly easy to achieve if a rebased revision
      was made visible by the working copy location. The rebase process would update
      somewhere else and the revision would become hidden.
      
      To work around this issue, we ensure rebased revisions remain visible for the
      whole process.
      
      This is a simple change suitable for stable. More subtle usage of unfiltered
      repository in rebase may solve this issue more cleanly.
      8a544fb6
  6. Jan 28, 2015
    • Mads Kiilerich's avatar
      extdiff: reintroduce backward compatibility with manual quoting of parameters · 01e5b732
      Mads Kiilerich authored
      72a89cf86fcd broke things ... and the following cleanups didn't fix all issues.
      It didn't work with the diffargs shipped in mergetools.rc with explicit
      quoting. Parameters would end up with being quoted twice - especially if they
      really needed quoting.
      
      To work around that, look for explicit quotes around the variables that will be
      substituted with proper quoting. Also accept an additional prefix so we can
      handle both
        --foo='$parent'
      and
        '--foo=$parent'
      
      It will however still fail if the user intentionally place the variable inside
      a quoted string, as in
        'parent $parent is on the left'
      There is currently no good way to handle that, short of knowing exactly which
      quoting mechanism will be used.
      01e5b732
    • Mads Kiilerich's avatar
      mergetools: drop incorrect quoting of diffargs variables · 6564ec38
      Mads Kiilerich authored
      72a89cf86fcd introduced automatic quoting of diffargs in a not entirely
      backwards compatible way. That rendered some of the configuration in
      mergetools.rc invalid. It would fail when running extdiff on a single file with
      a name that needed quoting.
      
      Before:
      
        $ hg config merge-tools.meld.diffargs
        -a --label='$plabel1' $parent --label='$clabel' $child
        $ hg --config extdiff.meld= -v --debug meld
        running "/usr/bin/meld -a --label=''sp ace@0'' '.../Z.b7a65a1d2f84/sp ace' --label=''sp ace'' '.../sp ace'" in ...
        meld: error: too many arguments (wanted 0-3, got 4)
      
      After:
      
        $ hg config merge-tools.meld.diffargs
        -a --label=$plabel1 $parent --label=$clabel $child
        $ hg --config extdiff.meld= -v --debug meld
        running "/usr/bin/meld -a --label='sp ace@0' '.../Z.b7a65a1d2f84/sp ace' --label='sp ace' '.../sp ace'" in ...
      (success)
      6564ec38
    • Katsunori FUJIWARA's avatar
      namespace: introduce logfmt to show l10n-ed messages for hg log correctly · 448bb32b
      Katsunori FUJIWARA authored
      Before this patch, "_()" is used incorrectly for "tag:" and
      "bookmark:" fields. "changeset_printer()" looks up keys composed at
      runtime, and it prevents "xgettext" command from getting strings to be
      translated from source files.
      
      Then, *.po files merged with updated "hg.pot" lose msgids for "tag:"
      and "bookmark:".
      
      This patch introduces "logfmt" information into "namespace" to show
      l10n-ed messages "hg log" (or "changeset_printer()") correctly.
      
      For similarity to other namespaces, this patch specifies "logfmt" for
      "branches" namespace, even though it isn't needed (branch information
      is handled in "changeset_printer()" specially).
      
      To find related code paths out easily, this patch adds "i18n: column
      positioning ..."  comment to the line composing "logfmt" by default,
      even though this line itself doesn't contain any strings to be
      translated.
      448bb32b
  7. Jan 27, 2015
  8. Jan 28, 2015
  9. Jan 27, 2015
  10. Jan 26, 2015
    • Matt Harbison's avatar
      largefiles: revert to lfilesrepo.status() being an unfiltered method · df463ca0
      Matt Harbison authored
      This effectively reverts 67d63ec85eb7, which caused some normal file copies to
      not be displayed as copies.  Other normal file copies could be displayed- the
      exact reason isn't clear.  This also adds two tests that were failing prior to
      this backout, so that this can be sorted out next cycle.
      
      The difference between copy cases that worked and those that didn't seemed to be
      in copies.pathcopies().  When largefiles isn't enabled for the changed test, or
      lfstatus is not set in the commands.status() override, 'y.ancestor(x) == x'.
      That wasn't true otherwise, which fell through to the _chain() method.  In this
      case, the copy is removed in the criss cross loop.
      
      'y.ancestor(x)' returns a context.changectx type, while 'x' is a lfilesctx type
      in the failing case.  I tried adding the ancestor method to the lfilesctx class
      to change the type of the ancestor context, however the context when printed as
      a string then gains a '+'.  This points to it being a context.committablectx,
      which clearly isn't correct for an ancestor.  Possibly the problem is the
      lfilesctx needs to subclass context.committablectx in some cases, but
      context.changectx in others, within the same invocation?  I'm not sure how to
      pull that off, and backing out this change is safer during the freeze.
      
      As to the status changing when a path is specified, I haven't looked into it
      yet.
      df463ca0
    • Matt Mackall's avatar
      test-tools: portability tweak · 0c4419fa
      Matt Mackall authored
      0c4419fa
  11. Jan 25, 2015
  12. Jan 10, 2015
  13. Jan 24, 2015
    • Siddharth Agarwal's avatar
      extensions: don't quit loading extensions in the middle if traceback is on · af73c05e
      Siddharth Agarwal authored
      This was introduced way back in 2006 (rev 1f6d520557ec) as sys.exit(0) if
      loading an extension failed when --traceback was on, then at some point morphed
      into a 'return 1' in a function that otherwise returns nothing.
      
      At this point, if ui.traceback is enabled and if loading an extension fails for
      whatever reason, including one as innocent as it not being present, we leave
      any extensions loaded so far in a bogus half-initialized state. That doesn't
      really make any sense.
      af73c05e
  14. Jan 23, 2015
  15. Jan 21, 2015
    • Katsunori FUJIWARA's avatar
      tests: invoke hg command indirectly from shell script to run on Windows · 42f3042c
      Katsunori FUJIWARA authored
      Before this patch, test-tag.t can't run successfully on Windows,
      because:
      
        - quoted hg command ('"hg"') prevents "hg.bat" from working correctly
          (only at testing with pure Python build)
      
          "%~f0" and "%~dp0hg" in "hg.bat" cause unexpected result in this
          case. BTW, quoted "\path\to\hg" works correctly.
      
        - "`pwd`" in the command line is expanded unexpectedly
      
          not "C:\path\to\TESTTMP" but "C;C:\path\to\TESTTMP"
      42f3042c
    • Martin von Zweigbergk's avatar
      log: evaluate filesets on working copy, not its parent · caff3675
      Martin von Zweigbergk authored
      When running "hg log 'set:added()'", we create two matchers: one used
      for producing the revset and one used for finding files to match. In
      1fd352aa08fc (graphlog: evaluate FILE/-I/-X filesets on the working
      dir, 2012-02-26), we started passing a revision argument along from
      what's currently in cmdutil._makelogrevset() to
      revset._matchfiles(). When the revision was an empty string, it
      referred to the working copy. This was subtly done with "repo[rev or
      None]". Then, in f2aeff8a87b6 (revset: avoid recalculating filesets,
      2014-10-22), that conversion from empty string to None was lost. Note
      that repo[''] is equivalent to repo['.'], not repo[None].
      
      The consequence of this, to the user, is that when running "hg log
      'set:added()'", the file matcher matches files added in the working
      copy, while the revset matcher matches revisions that touch files
      added in the parent of the working copy. As a result, only revisions
      that touch any files added in the parent of the working copy will be
      considered, but they will only be included if they also touch files
      added in the working copy.
      
      Fix the bug by converting '' to None again, but make it a little more
      explicit this time (plus, we now have tests for it).
      caff3675
    • Martin von Zweigbergk's avatar
  16. Jan 23, 2015
  17. Jan 21, 2015
Loading