# fix

Contents

- Description
- Commands
  - File content management

rewrite file content in changesets or working copy (EXPERIMENTAL)

# Description

Provides a command that runs configured tools on the contents of modified files, writing back any fixes to the working copy or replacing changesets.

Fixer tools are run in the repository's root directory. This allows them to read configuration files from the working copy, or even write to the working copy. The working copy is not updated to match the revision being fixed. In fact, several revisions may be fixed in parallel. Writes to the working copy are not amended into the revision being fixed; fixer tools MUST always read content to be fixed from stdin, and write fixed file content back to stdout.

Here is an example configuration that causes `hg fix` to apply automatic formatting fixes to modified lines in C++ code:

    [fix]
    clang-format:command=clang-format --assume-filename={rootpath}
    clang-format:linerange=--lines={first}:{last}
    clang-format:pattern=set:**.cpp or **.hpp

The :command suboption forms the first part of the shell command that will be used to fix a file. The content of the file is passed on standard input, and the fixed file content is expected on standard output. Any output on standard error will be displayed as a warning. If the exit status is not zero, the file will not be affected. A placeholder warning is displayed if there is a non-zero exit status but no standard error output. Some values may be substituted into the command:

    {rootpath}  The path of the file being fixed, relative to the repo root
    {basename}  The name of the file being fixed, without the directory path

If the :linerange suboption is set, the tool will only be run if there are changed lines in a file. The value of this suboption is appended to the shell command once for every range of changed lines in the file. Some values may be substituted into the command:

    {first}   The 1-based line number of the first line in the modified range
    {last}    The 1-based line number of the last line in the modified range

Deleted sections of a file will be ignored by :linerange, because there is no corresponding line range in the version being fixed.

By default, tools that set :linerange will only be executed if there is at least one changed line range. This is meant to prevent accidents like running a code formatter in such a way that it unexpectedly reformats the whole file. If such a tool needs to operate on unchanged files, it should set the :skipclean suboption to false.

The :pattern suboption determines which files will be passed through each configured tool. See `hg help patterns` for possible values. However, all patterns are relative to the repo root, even if that text says they are relative to the current working directory. If there are file arguments to `hg fix`, the intersection of these patterns is used.

There is also a configurable limit for the maximum size of file that will be processed by `hg fix`:

    [fix]
    maxfilesize = 2MB

Normally, execution of configured tools will continue after a failure (indicated by a non-zero exit status). It can also be configured to abort after the first such failure, so that no files will be affected if any tool fails. This abort will also cause `hg fix` to exit with a non-zero status:

    [fix]
    failure = abort

When multiple tools are configured to affect a file, they execute in an order defined by the :priority suboption. The priority suboption has a default value of zero for each tool. Tools are executed in order of descending priority. The execution order of tools with equal priority is unspecified. For example, you could use the 'sort' and 'head' utilities to keep only the 10 smallest numbers in a text file by ensuring that 'sort' runs before 'head':

    [fix]
    sort:command = sort -n
    head:command = head -n 10
    sort:pattern = numbers.txt
    head:pattern = numbers.txt
    sort:priority = 2
    head:priority = 1

To account for changes made by each tool, the line numbers used for incremental formatting are recomputed before executing the next tool. So, each tool may see different values for the arguments added by the :linerange suboption.

Each fixer tool is allowed to return some metadata in addition to the fixed file content. The metadata must be placed before the file content on stdout, separated from the file content by a zero byte. The metadata is parsed as a JSON value (so, it should be UTF-8 encoded and contain no zero bytes). A fixer tool is expected to produce this metadata encoding if and only if the :metadata suboption is true:

    [fix]
    tool:command = tool --prepend-json-metadata
    tool:metadata = true

The metadata values are passed to hooks, which can be used to print summaries or perform other post-fixing work. The supported hooks are:

    "postfixfile"
      Run once for each file in each revision where any fixer tools made changes
      to the file content. Provides "$HG_REV" and "$HG_PATH" to identify the file,
      and "$HG_METADATA" with a map of fixer names to metadata values from fixer
      tools that affected the file. Fixer tools that didn't affect the file have a
      value of None. Only fixer tools that executed are present in the metadata.

    "postfix"
      Run once after all files and revisions have been handled. Provides
      "$HG_REPLACEMENTS" with information about what revisions were created and
      made obsolete. Provides a boolean "$HG_WDIRWRITTEN" to indicate whether any
      files in the working copy were updated. Provides a list "$HG_METADATA"
      mapping fixer tool names to lists of metadata values returned from
      executions that modified a file. This aggregates the same metadata
      previously passed to the "postfixfile" hook.

# Commands

## File content management

### fix

rewrite file content in changesets or working directory:

    hg fix [OPTION]... [FILE]...

Runs any configured tools to fix the content of files. (See `hg help -e fix` for details about configuring tools.) Only affects files with changes, unless file arguments are provided. Only affects changed lines of files, unless the --whole flag is used. Some tools may always affect the whole file regardless of --whole.

If --working-dir is used, files with uncommitted changes in the working copy will be fixed. Note that no backup are made.

If revisions are specified with --source, those revisions and their descendants will be checked, and they may be replaced with new revisions that have fixed file content. By automatically including the descendants, no merging, rebasing, or evolution will be required. If an ancestor of the working copy is included, then the working copy itself will also be fixed, and the working copy will be updated to the fixed parent.

When determining what lines of each file to fix at each revision, the whole set of revisions being fixed is considered, so that fixes to earlier revisions are not forgotten in later ones. The --base flag can be used to override this default behavior, though it is not usually desirable to do so.

Options:

`--all` | fix all non-public non-obsolete revisions
`--base <REV[+]>`
| revisions to diff against (overrides automatic selection, and applies to every revision being fixed)
`-r, --rev <REV[+]>`
| revisions to fix (ADVANCED)
`-s, --source <REV[+]>`
| fix the specified revisions and their descendants
`-w, --working-dir`
| fix the working directory
`--whole` | always fix every line of a file

[+] marked option can be specified multiple times