Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. Oct 25, 2024
  3. Oct 24, 2024
    • Raphaël Gomès's avatar
      py-3-13: stabilize the docstring output across all supported Python versions · 51057ab0dffa
      Raphaël Gomès authored
      Python 3.13 now trims indents from docstrings at compilation time
      (to save space in .pyc), so all of our helptext is affected.
      The indentation has never served a user-facing purpose and was more here
      because nobody cared enough to remove it: we gain some screen space this way.
      Rather than undo the transformation (which isn't really possible since the
      transform also deletes leading/trailing whitespace), we align the behavior
      of older Python versions with that of 3.13.
      
      Unfortunately, this means breaking some of the translations. I've only
      touched the ones that need to work for some tooling tests to pass, but
      I do not have the time to fix the rest of them across all languages, since
      they cannot be done in an automated way. i18n updates have been basically
      abandonned for a good while now, hopefully someone cares enough to bring them
      back.
      51057ab0dffa
  4. Mar 10, 2023
  5. Jan 11, 2021
    • Nikita Slyusarev's avatar
      convert: option to set date and time for svn commits · 7525e77b5eac
      Nikita Slyusarev authored
      Converting to subversion repository is not preserving original commit dates as
      it may break some subversion functionality if commit dates are not monotonically
      increasing.
      
      This patch adds `convert.svn.dangerous-set-commit-dates` configuration option
      to change this behaviour and enable commit dates convertion for those who want
      to take risks.
      
      Subversion always uses commit dates with UTC timezone, so only timestamps
      are used.
      
      Test `test-convert-svn-sink.t` uses `svnxml.py` script to dump history of svn
      repositories. Atm the script is not printing `date` field from svn log. This
      patch changes this to allow checks on correctness of date and time convertion.
      
      Documentation is updated. Additional test case is added to test commit dates
      convertion.
      
      Differential Revision: https://phab.mercurial-scm.org/D9721
      7525e77b5eac
  6. Jul 14, 2019
    • sliquister's avatar
      convert: add a config option to help doing identity hg->hg conversion · d98ec36be808
      sliquister authored
      I want to change the computation of the list of files modified by a
      commit. In principle, this would simply change a cache. But since this
      information is stored in commits rather than a cache, changing it
      means changing commit hashes (going forward).
      
      Some users rely on the convert extension from hg to hg not changing
      hashes when nothing changes (usually). Allow these users to preserve
      hashes despite changes to the changelog files computation by reusing
      these files lists when the manifest is unchanged (since these files
      list are derived from the manifest).
      
      Differential Revision: https://phab.mercurial-scm.org/D6643
      d98ec36be808
  7. Oct 13, 2018
  8. Sep 19, 2018
  9. Aug 18, 2018
    • Matt Harbison's avatar
      tests: conditionalize out tests that msys is mangling · 2dfc22620a54
      Matt Harbison authored
      This was exposed by ac0a87160012.  The paths for convert and ssh respectively
      are being turned into:
      
         $TESTTMP\bzr+ssh:\foobar@selenic.com\baz\.hg
      
         'C:\\C:\\Users\\Matt\\AppData\\Local\\Temp\\hgtests.8awa9x\\child1\\test-ssh-bundle1.t-sshv2\\nonexistent\\.hg
      
      The errno value raised is 123, and the message is
      
         The filename, directory name, or volume label syntax is incorrect
      2dfc22620a54
  10. Jul 05, 2018
  11. Jun 05, 2018
  12. Jun 04, 2018
  13. May 24, 2018
    • Denis Laxalde's avatar
      transaction-summary: show phase changes statistics in pull/unbundle · eb9835014d20
      Denis Laxalde authored
      Upon pull or unbundle, we display a message with the number of
      changesets which phase became public. Noticeably, this new message would
      appear even if no new changeset were added (below the "no changes found"
      message), thus indicating that something actually happened to the local
      repository.
      eb9835014d20
  14. Apr 04, 2018
    • Gregory Szorc's avatar
      simplestore: use a custom store for the simple store repo · c2c8962a9465
      Gregory Szorc authored
      Before, we used the default store, which was based on fncache
      and dotencode. After attempting to port tests to work with the
      simple store, I realized that fncache was more trouble than it is
      worth.
      
      This commit implements a proper store type for the simple repo -
      one that isn't based off fncache.
      
      This causes a number of new test failures because of tests
      expecting the full fncache store filename encoding. I may
      extend the store format in a subsequent commit to take the
      filename encoding parts of fncache that we can take
      (basically everything except hash encoding, since that isn't
      reversible). But for now, let's use encoded store.
      
      As part of this, we implement proper requirements support for
      repos created with the simple store. This should have been
      done from the beginning, as a requirement is needed to lock
      out clients that don't understand a storage format.
      
      A new hghave feature advertising the presence of fncache in repos
      has been added. Most tests touching the fncache are now conditional
      on that feature.
      
      Other tests have added the optional repo requirement to output.
      
      Differential Revision: https://phab.mercurial-scm.org/D3095
      c2c8962a9465
    • Gregory Szorc's avatar
      tests: conditionalize tests based on presence of revlogs for files · cbc4425e81b5
      Gregory Szorc authored
      ~85 tests don't like our non-revlog file store for various reasons.
      
      This commit introduces hghave functionality for declaring and querying
      repository features. By default, we assume repositories have
      revlog-based file storage. But if the HGREPOFEATURES environment
      variable is set, we can override the default set of repository
      features. If you run the test harness with our simplestorerepo
      extension and an environment variable set to the proper value, you
      can override the hghave defaults to agree with simplestorerepo's
      version of reality.
      
      Various tests have been modified so behavior dependent on revlog-based
      file storage is marked as such.
      
      This fixes a handful of test failures with our custom file storage
      extension. But dozens remain. The point of this commit is to demonstrate
      how tests will need to be modified to account for custom storage
      implementations.
      
      TBH, I'm not convinced hghave is the proper layer for repository
      feature detection. I /think/ we'll eventually want something in
      run-tests.py itself. But that would require inventing a new primitive
      in the test harness. This is all very alpha at the moment. So I think
      hghave is an acceptable place to hang this feature detection. I think
      the right time to be thinking about integrating this into run-tests.py
      is *after* we have a stable alternate storage implementation in core.
      For now, let's try to make progress towards the idea of an alternate
      storage backend.
      
      Differential Revision: https://phab.mercurial-scm.org/D3030
      cbc4425e81b5
  15. Dec 11, 2017
    • Matt Harbison's avatar
      tests: remove (glob) annotations that were only for '\' matches · 4441705b7111
      Matt Harbison authored
      # skip-blame because this was mechanically rewritten the following script.  I
      ran it on both *.t and *.py, but none of the *.py changes were proper.  All *.t
      ones appear to be, and they run without addition failures on both Windows and
      Linux.
      
        import argparse
        import os
        import re
      
        ap = argparse.ArgumentParser()
        ap.add_argument('path', nargs='+')
        opts = ap.parse_args()
      
        globre = re.compile(r'^(.*) \(glob\)(.*)$')
      
        for p in opts.path:
            tmp = p + '.tmp'
            with open(p, 'rb') as src, open(tmp, 'wb') as dst:
                for line in src:
                    m = globre.match(line)
                    if not m or '$LOCALIP' in line or '*' in line:
                        dst.write(line)
                        continue
                    if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
                        dst.write(line)
                        continue
                    dst.write(m.group(1) + m.group(2) + '\n')
            os.unlink(p)
            os.rename(tmp, p)
      4441705b7111
  16. Jul 10, 2017
    • Katsunori FUJIWARA's avatar
      convert: transcode CVS log messages by specified encoding (issue5597) · 0823f0983eaa
      Katsunori FUJIWARA authored
      Converting from CVS to Mercurial assumes that CVS log messages in "cvs
      rlog" output are encoded in UTF-8 (or basic Latin-1). But cvs itself
      is usually unaware of encoding of log messages, in practice.
      
      Therefore, if there are commits, of which log message is encoded in
      other than UTF-8, log message of corresponded revisions in the
      converted repository will be broken.
      
      To avoid such broken log messages, this patch transcodes CVS log
      messages by encoding specified via "convert.cvsps.logencoding"
      configuration.
      
      This patch accepts multiple encoding for convenience, because
      "multiple encoding mixed in a repository" easily occurs. For example,
      UTF-8 (recent POSIX), cp932 (Windows), and EUC-JP (legacy POSIX) are
      well known encoding for Japanese.
      0823f0983eaa
  17. Jun 10, 2017
  18. Jan 14, 2017
    • Gregory Szorc's avatar
      convert: remove "replacecommitter" action · c5bf2e8ec18c
      Gregory Szorc authored
      As pointed out by Yuya, this action doesn't add much (any?) value.
      c5bf2e8ec18c
    • Gregory Szorc's avatar
      convert: config option to control Git committer actions · 2cbbd4622ab0
      Gregory Szorc authored
      When converting a Git repository to Mercurial at Mozilla, I encountered
      a scenario where I didn't want `hg convert` to automatically add the
      "committer: <committer>" line to commit messages. While I can hack around
      this by rewriting the Git commit before it is fed into `hg convert`,
      I figured it would be a useful knob to control.
      
      This patch introduces a config option that allows lots of control
      over the committer value. I initially implemented this as a single
      boolean flag to control whether to save the committer message. But
      then there was feedback that it would be useful to save the committer
      in extra data. While this patch doesn't implement support for saving
      in extra data, it does add a mechanism for extending which actions
      to take on the committer field. We should be able to easily add
      actions to save in extra data.
      
      Some of the implemented features weren't asked for. But I figured they
      could be useful. If nothing else they demonstrate the extensibility
      of this mechanism.
      2cbbd4622ab0
  19. Dec 23, 2016
    • Gregory Szorc's avatar
      convert: add config option to control storing original revision · ced0d686ecb3
      Gregory Szorc authored
      common.commit.__init__ sets saverev=True by default. The side effect
      of this is that the hg sink will always set the "convert_revision"
      extras key to the commit being converted.
      
      This patch adds a config option to disable this behavior.
      
      While most consumers will want "convert_revision" to be a) written
      b) with the exact Git commit that was converted, some have use cases
      that prefer otherwise. In my case, I am performing significant
      rewrites of a Git repository *before* it is fed into `hg convert`.
      I have to do this because `hg convert` does not easily support the kind
      of transform I desire, even with extensions. (For the curious, I am
      "linearizing" the history of a GitHub repo by removing merge commits
      which add little value to the final history. It isn't easy to do this
      during `hg convert` because of Mercurial's file copy/rename metadata
      requirements.)
      
      In my scenario, my pre-convert transform stores a "convert_revision"
      key in the Git commit object containing the original Git commit ID.
      I want this original Git commit ID carried forward to Mercurial. By
      disabling the setting of this extra during `hg convert` and copying
      the value from the Git commit object, I can have the final
      "convert_revision" extra key contain the original Git commit ID. An
      added test verifies this exact scenario.
      
      This feature could likely be implemented for other VCS sources. But
      until someone needs the feature, I'm inclined to hold off implementing.
      ced0d686ecb3
    • Gregory Szorc's avatar
      convert: add config option to copy extra keys from Git commits · 1f21a6835604
      Gregory Szorc authored
      Git commit objects support storing arbitrary key-value metadata. While
      there is no user-facing mechanism in Git to record these values, some
      tools do record data here.
      
      Currently, `hg convert` only handles the "author," "committer," and
      "parent" keys in Git commit objects. All other keys are ignored. This
      means that any custom keys are lost when converting Git repos to
      Mercurial.
      
      This patch implements support for copying a whitelist of extra keys
      from Git commit objects to the "extras" dict of the destination. As
      the added tests demonstate, this allows extra metadata to be preserved
      during the conversion process.
      
      This patch stops short of converting all metadata to "extras." We could
      potentially implement this via `convert.git.extrakeys=*` or similar.
      But copying everything by default is a bit dangerous because if Git
      adds new keys to commit objects, we could find ourselves copying
      things that shouldn't be copied!
      
      This patch also assumes the source key is the same as the destination
      key. We could implement support for prefixing the output key to
      distinguish it as coming from Git. But until this feature is needed,
      I'm inclined to hold off implementing it.
      1f21a6835604
  20. 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
  21. 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
  22. 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
  23. May 06, 2016
  24. 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
  25. Jan 12, 2016
  26. 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
  27. 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
  28. Jul 30, 2015
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. Sep 12, 2014
Loading