Skip to content
Snippets Groups Projects
  1. Dec 18, 2016
    • Gregory Szorc's avatar
      convert: config option for git rename limit · ea3540e66fd8
      Gregory Szorc authored
      By default, Git applies rename and copy detection to 400 files. The
      diff.renamelimit config option and -l argument to diff commands can
      override this.
      
      As part of converting some repositories in the wild, I was hitting
      the default limit. Unfortunately, the warnings that Git prints in this
      scenario are swallowed because the process running functionality in
      common.py redirects stderr to /dev/null by default. This seems like
      a bug, but a bug for another day.
      
      This commit establishes a config option to send the rename limit
      through to `git diff-tree`. The added tests demonstrate a too-low
      rename limit doesn't result in copy metadata being recorded.
      ea3540e66fd8
  2. Oct 09, 2016
    • Pierre-Yves David's avatar
      help: backout f3c4edfd35e1 (mark boolean flags with [no-] in help) for now · d65e246100ed
      Pierre-Yves David authored
      The ability to negate any boolean flags itself is great, but I think we are not
      ready to expose the help side of it yet.
      
      First, while there exist a handful of such flags whose default value can be
      changed (eg: git diff, patchwork confirmation), there is only a few of them. The
      users who benefit the most from this change are alias users and large
      installation that can deploy extension to change behavior (eg: facebook
      tweakdefault).  So the majority of user who will be affected by a large change
      to command help that is not yet relevant to them. (I expect this to become
      relevant when ui.progressive start to exists).
      
      Below is an example of the impact of the new help on 'hg help diff':
      
        -r --rev REV [+]              revision
        -c --change REV               change made by revision
        -a --[no-]text                treat all files as text
        -g --[no-]git                 use git extended diff format
           --[no-]nodates             omit dates from diff headers
           --[no-]noprefix            omit a/ and b/ prefixes from filenames
        -p --[no-]show-function       show which function each change is in
           --[no-]reverse             produce a diff that undoes the changes
        -w --[no-]ignore-all-space    ignore white space when comparing lines
        -b --[no-]ignore-space-change ignore changes in the amount of white space
        -B --[no-]ignore-blank-lines  ignore changes whose lines are all blank
        -U --unified NUM              number of lines of context to show
           --[no-]stat                output diffstat-style summary of changes
           --root DIR                 produce diffs relative to subdirectory
        -I --include PATTERN [+]      include names matching the given patterns
        -X --exclude PATTERN [+]      exclude names matching the given patterns
        -S --[no-]subrepos            recurse into subrepositories
      
      Another issue with the current state of help, the default value for the
      flag is not conveyed to the user. For example in the 'backout' help, there is
      no real distinction between "--[no-]backup" (default to True) and "--[no-]keep"
      (default) to False:
      
        --[no-]backup        no backups
        --[no-]keep          do not modify working directory during strip
      
      In addition, I've discussed with Augie Fackler and the last batch of the work on
      this have burned him out quite some. Therefore he is not intending to perform
      any more work on this topic. Quoting him, he would rather see the help part
      backed out than spending more time on it.
      
      I do not think we are ready to expose this to users in 4.0 (freeze in a week),
      especially because we cannot expect quick improvement on these aspect as this
      topic no longer have an owner. We should be able to reintroduce that change in
      the future when someone get back on it and the main issues are solves:
      
      * Introduction of  ui.progressive makes it relevant for a majority of user,
      * Current default value are efficiently conveyed to the user.
      
      (In addition, the excerpt from diff help show that we still have some issue with
      some negative option like '--nodates' so further improvement are probably
      welcome there.)
      d65e246100ed
  3. Sep 14, 2016
    • Augie Fackler's avatar
      help: mark boolean flags with [no-] to explain that they can be negated · f3c4edfd35e1
      Augie Fackler authored
      That is, help gets tweaked thus:
      
        global options ([+] can be repeated):
         -v --[no-]verbose      enable additional output
      
      
      Other proposals have included:
      
        global options ([+] can be repeated, options marked [?] are boolean flags):
         -v --verbose[?]        enable additional output
      
      and
      
        global options ([+] can be repeated, options marked [^] are boolean flags):
         -v --verbose[^]        enable additional output
      
      which avoid the unfortunate visual noise in this patch. In this
      version's favor, it's consistent with what I'm used to seeing in man
      pages and similar documentation venues.
      f3c4edfd35e1
  4. May 06, 2016
  5. Apr 07, 2016
    • Blake Burkhart's avatar
      convert: pass absolute paths to git (SEC) · a56296f55a5e
      Blake Burkhart authored
      Fixes CVE-2016-3105 (1/1).
      
      Previously, it was possible for the repository path passed to git-ls-remote
      to be misinterpreted as a URL.
      
      Always passing an absolute path to git is a simple way to avoid this.
      3.8.1
      a56296f55a5e
  6. Jan 12, 2016
  7. Aug 25, 2015
    • Durham Goode's avatar
      convert: add convert.git.skipsubmodules option · e63d05fbae84
      Durham Goode authored
      This adds an option to not pull in gitsubmodules during a convert. This is
      useful when converting large git repositories where gitsubmodules were allowed
      historically, but are no longer wanted.
      e63d05fbae84
  8. Jul 22, 2015
    • Eugene Baranov's avatar
      convert: when converting from Perforce use original local encoding by default · b810b59eca62
      Eugene Baranov authored
      On Windows Perforce command line client uses default system locale to encode
      output. Using 'latin_1' causes locale-specific characters to be replaced with
      question marks. With this patch we will use default locale by default whilst
      allowing to specify it explicity with 'convert.p4.encoding' config option.
      
      This is a potentially breaking change for any scripts relying on output treated
      as in 'latin_1' encoding.
      
      Also because hgext.convert.convcmd overwrites detected default system locale
      with UTF-8 we had to introduce an import cycle in hgext.convert.p4 to retrieve
      originally detected encoding from hgext.convert.convcmd.
      b810b59eca62
  9. Jul 30, 2015
  10. Jul 14, 2015
    • Durham Goode's avatar
      convert: allow customizing git remote prefix · d9133e89d39d
      Durham Goode authored
      Previously all git remotes were created as "remote/foo". This patch adds a
      configuration option for deciding what the prefix should be. This is useful if
      you want the bookmarks to be "origin/foo" like they are in git, or if you're
      integrating with the remotenames extension and don't want the local remote/foo
      bookmarks to overlap with the remote foo bookmarks.
      d9133e89d39d
  11. Jul 08, 2015
    • Durham Goode's avatar
      convert: add config for recording the source name · c9093d4d1ff6
      Durham Goode authored
      This creates the convert.hg.sourcename config option which will embed a user
      defined name into each commit created by the convert. This is useful when using
      the convert extension to merge several repositories together and we want to
      record where each commit came from.
      c9093d4d1ff6
    • Durham Goode's avatar
      convert: add support for specifying multiple revs · baea47cafe75
      Durham Goode authored
      Previously convert could only take one '--rev'. This change allows the user to
      specify multiple --rev entries. For instance, this could allow converting
      multiple branches (but not all branches) at once from git.
      
      In this first patch, we disable support for this for all sources.  Future
      patches will enable it for select sources (like git).
      baea47cafe75
  12. Jun 29, 2015
    • Durham Goode's avatar
      convert: add config to not convert tags · 86fe3c404c1e
      Durham Goode authored
      In some cases we do not want to convert tags from the source repo to be tags in
      the target repo (for instance, in a large repository, hgtags cause scaling
      issues so we want to avoid them). This adds a config option to disable
      converting tags.
      86fe3c404c1e
  13. May 29, 2015
    • Matt Harbison's avatar
      convert: support incremental conversion with hg subrepos · daf9f7ee2a5c
      Matt Harbison authored
      This was implied in issue3486, which specifically asked for subrepo support in
      lfconvert.  Now that lfconvert uses the convert extension internally when going
      to normal files, the issue is half fixed.  But now even non largefile repos
      benefit when other transformations are needed.
      
      Supporting a full subrepo tree conversion from a single command doesn't seem
      reasonable, given the number of options that can be provided, and the
      transformations that would need to occur when entering a subrepo (consider
      'filemap' paths).  Instead, this allows the user to incrementally convert each
      hg subrepo from bottom up like so:
      
        # so convert knows the dest type when it sees a non empty dest dir
        $ hg init converted
      
        $ hg convert orig/sub1 converted/sub1
        $ hg convert orig/sub2 converted/sub2
        $ hg convert orig converted
      
      This allows different options to be applied to different subrepos more readily.
      It assumes the shamap is in the default location in each converted subrepo for
      simplicity.  It also allows for a subrepo to be cloned into place, in case _it_
      doesn't need a conversion.  I was able to convert away from using
      largefiles/bfiles in several subrepos with this mechanism.
      daf9f7ee2a5c
  14. Sep 23, 2014
    • Siddharth Agarwal's avatar
      convert: change default for git rename detection to 50% · 6b6da715cb96
      Siddharth Agarwal authored
      This default mirrors the default for 'git diff'. Other commands have slightly
      different defaults -- for example, the move/copy detection for 'git blame'
      assumes that a hunk is moved if more than 40 alphanumeric characters are the
      same, or copied if more than 20 alphanumeric characters are the same. 50% seems
      to be the most common default, though.
      6b6da715cb96
  15. Sep 12, 2014
  16. Aug 26, 2014
    • Mads Kiilerich's avatar
      convert: introduce --full for converting all files · 35ab037de989
      Mads Kiilerich authored
      Convert will normally only process files that were changed in a source
      revision, apply the filemap, and record it has a change in the target
      repository. (If it ends up not really changing anything, nothing changes.)
      
      That means that _if_ the filemap is changed before continuing an incremental
      convert, the change will only kick in when the files it affects are modified in
      a source revision and thus processed.
      
      With --full, convert will make a full conversion every time and process
      all files in the source repo and remove target repo files that shouldn't be
      there. Filemap changes will thus kick in on the first converted revision, no
      matter what is changed.
      
      This flag should in most cases not make any difference but will make convert
      significantly slower.
      
      Other names has been considered for this feature, such as "resync", "sync",
      "checkunmodified", "all" or "allfiles", but I found that they were less obvious
      and required more explanation than "full" and were harder to describe
      consistently.
      35ab037de989
  17. Aug 12, 2014
    • Matt Mackall's avatar
      help: tweak --verbose command help hint · 26f7c8033bed
      Matt Mackall authored
      We used to have two slightly different message which people wouldn't read...
      and then complain that they couldn't find the global options or examples.
      
      So we unify them into one message that's upfront that STUFF IS
      INTENTIONALLY HIDDEN and that looks more like our normal hint style.
      26f7c8033bed
  18. Apr 15, 2014
    • Mads Kiilerich's avatar
      convert: backout 81cf597dafa9 and a3545c3104aa -closemap · 78b15ad2f968
      Mads Kiilerich authored
      Closemap solves a very specific use case. It would be better to have a more
      generic solution than to have to maintain this forever.
      
      Closemap has not been released yet and removing it now will not break any
      backward compatibility contract.
      
      There is no test coverage for closemap but it seems like the same can be
      achieved with a simple and much more powerful custom extension:
      
      import hgext.convert.hg
      class source(hgext.convert.hg.mercurial_source):
          def getcommit(self, rev):
              c = super(source, self).getcommit(rev)
              if rev in ['''
      d643f67092ff123f6a192d52f12e7d123dae229f
      9117c6561b0b
      f368a1c302d5
      ''']:
                  c.extra = c.extra.copy()
                  c.extra['close'] = '1'
              return c
      hgext.convert.hg.mercurial_source = source
      78b15ad2f968
    • Mads Kiilerich's avatar
      convert: backout b75a04502ced and 9616b03113ce - tagmap · 5236c7a72a2d
      Mads Kiilerich authored
      Tagmap solves a very specific use case. It would be better to have a more
      generic solution than to have to maintain this forever.
      
      Tagmap has not been released yet and removing it now will not break any
      backward compatibility contract.
      
      There is no test coverage for tagmap but it seems like the same can be achieved
      with a (relatively) simple and much more powerful custom extension:
      
      import hgext.convert.hg
      def f(tag):
          return tag.replace('some', 'other')
      class source(hgext.convert.hg.mercurial_source):
          def gettags(self):
              return dict((f(tag), node)
                          for tag, node in in super(source, self).gettags().items())
          def getfile(self, name, rev):
              data, flags = super(source, self).getfile(name, rev)
              if name == '.hgtags':
                  data = ''.join(l[:41] + f(l[41:]) + '\n' for l in data.splitlines())
              return data, flags
      hgext.convert.hg.mercurial_source = source
      5236c7a72a2d
  19. Apr 13, 2014
  20. Mar 19, 2014
  21. Mar 18, 2014
  22. Jan 22, 2014
  23. Jan 21, 2014
  24. Nov 15, 2013
  25. Jul 19, 2013
    • Mads Kiilerich's avatar
      convert: introduce hg.revs to replace hg.startrev and --rev with a revset · e271970b9821
      Mads Kiilerich authored
      The existing knobs for controlling which revisions to convert were often
      insufficient. Revsets is a shiny hammer that provides a better solution.
      
      Revsets has been introduced in --rev handling in a lot of other places while
      being more or less backwards compatible. Doing the same here would be a much
      more elegant ... but that would unfortunately not work in this case.  "--rev 7"
      used to mean revision 0 to 7 - it would be an unacceptable change if it
      suddenly just meant revision 7.
      
      Instead we introduce a new configuration setting. It will only work for
      Mercurial repositories so adding a new commandline option for it would not be a
      nice solution.
      
      There is no way to use the fancy deprecation markup for configuration settings
      so we just remove the documentation of hg.startrev.
      e271970b9821
    • Mads Kiilerich's avatar
      convert: fix description of 'convert --rev' · 1ce3f56b879f
      Mads Kiilerich authored
      1ce3f56b879f
  26. Mar 23, 2013
    • Constantine Linnick's avatar
      convert: add closesort algorithm to mercurial sources · 05acdf8e1f23
      Constantine Linnick authored
      If you actively work with branches, sometimes you need to close old branches
      which last commited hundreds revisions ago. After close you will see long
      lines in graph visually spoiling history. This sort only moves closed
      revisions as close as possible to parents and does not increase storage size
      as datesort do.
      05acdf8e1f23
  27. Jan 14, 2013
  28. Jan 07, 2013
    • kiilerix's avatar
      dispatch: show empty filename in OSError aborts · 720308f741cb
      kiilerix authored
      Mercurial would sometimes exit with:
        abort: No such file or directory
      where str of the actual OSError exception was the more helpful:
        [Errno 2] No such file or directory: ''
      
      The exception will now always show the filename and quote it:
        abort: No such file or directory: ''
      720308f741cb
  29. Nov 18, 2012
    • Julian Cowley's avatar
      convert: add config option to use the local time zone · 337d728e644f
      Julian Cowley authored
      The default for the time zone offset in a converted changeset has
      always been 0 (UTC).  With this patch, the converted changeset is
      modified so that the local offset from UTC is specified as the time
      zone offset.
      
      The option is specified as the boolean convert.localtimezone (default
      False).  Example usage:
      
          hg convert -s cvs --config convert.localtimezone=True example-cvs example-hg
      
      IMPORTANT: the patch only applies to conversions from cvs or svn.
      The documentation for the option only appears in those two sections
      in the convert help text.
      337d728e644f
  30. Oct 18, 2012
    • Katsunori FUJIWARA's avatar
      help: indicate help omitting if help document is not fully displayed · b623e323c561
      Katsunori FUJIWARA authored
      Before this patch, there is no information about whether help document
      is fully displayed or not.
      
      So, some users seem to misunderstand "-v" for "hg help" just as "the
      option to show list of global options": experience on "hg help -v" for
      some commands not containing verbose containers may strengthen this
      misunderstanding.
      
      Such users have less opportunity for noticing omitted help document,
      and this may cause insufficient understanding about Mercurial.
      
      This patch indicates help omitting, if help document is not fully
      displayed.
      
      For command help, the message below is displayed at the end of help
      output, if help document is not fully displayed:
      
          use "hg -v help xxxx" to show more complete help and the global
          options
      
      and otherwise:
      
          use "hg -v help xxxx" to show the global options
      
      For topics and extensions help, the message below is displayed, only
      if help document is not fully displayed:
      
          use "hg help -v xxxx" to show more complete help
      
      This allows users to know whether there is any omitted information or
      not exactly, and can trigger "hg help -v" invocation.
      
      This patch causes formatting help document twice, to switch messages
      one for omitted help, and another for not omitted. This decreases
      performance of help document formatting, but it is not mainly focused
      at help command invocation, so this wouldn't become problem.
      b623e323c561
  31. Aug 15, 2012
  32. Aug 08, 2012
  33. Jul 25, 2012
    • Katsunori FUJIWARA's avatar
      doc: unify section level between help topics · 979b107eaea2
      Katsunori FUJIWARA authored
      Some help topics use "-" for the top level underlining section mark,
      but "-" is used also for the top level categorization in generated
      documents: "hg.1.html", for example.
      
      So, TOC in such documents contain "sections in each topics", too.
      
      This patch changes underlining section mark in some help topics to
      unify section level in generated documents.
      
      After this patching, levels of each section marks are:
      
        level0
        """"""
          level1
          ======
            level2
            ------
              level3
              ......
                level4
                ######
      
      And use of section markers in each documents are:
      
        - mercurial/help/*.txt can use level1 or more
          (now these use level1 and level2)
      
        - help for core commands can use level2 or more
          (now these use no section marker)
      
        - descriptions of extensions can use level2 or more
          (now hgext/acl uses level2)
      
        - help for commands defined in extension can use level4 or more
          (now "convert" of hgext/convert uses level4)
      
      "Level0" is used as top level categorization only in "doc/hg.1.txt"
      and the intermediate file generated by "doc/gendoc.py", so end users
      don't see it in "hg help" outoput and so on.
      979b107eaea2
  34. Jul 26, 2012
Loading