A script that implements uppercasing of specific lines in a file. This

approximates the behavior of code formatters well enough for our tests.

  $ UPPERCASEPY="$TESTTMP/uppercase.py"

  $ cat > $UPPERCASEPY <<EOF

  > import sys

  > from mercurial.utils.procutil import setbinary

  > setbinary(sys.stdin)

  > setbinary(sys.stdout)

  > lines = set()

  > for arg in sys.argv[1:]:

  >   if arg == 'all':

  >     sys.stdout.write(sys.stdin.read().upper())

  >     sys.exit(0)

  >   else:

  >     first, last = arg.split('-')

  >     lines.update(range(int(first), int(last) + 1))

  > for i, line in enumerate(sys.stdin.readlines()):

  >   if i + 1 in lines:

  >     sys.stdout.write(line.upper())

  >   else:

  >     sys.stdout.write(line)

  > EOF

  $ TESTLINES="foo\nbar\nbaz\nqux\n"

  $ printf $TESTLINES | "$PYTHON" $UPPERCASEPY

  foo

  bar

  baz

  qux

  $ printf $TESTLINES | "$PYTHON" $UPPERCASEPY all

  FOO

  BAR

  BAZ

  QUX

  $ printf $TESTLINES | "$PYTHON" $UPPERCASEPY 1-1

  FOO

  bar

  baz

  qux

  $ printf $TESTLINES | "$PYTHON" $UPPERCASEPY 1-2

  FOO

  BAR

  baz

  qux

  $ printf $TESTLINES | "$PYTHON" $UPPERCASEPY 2-3

  foo

  BAR

  BAZ

  qux

  $ printf $TESTLINES | "$PYTHON" $UPPERCASEPY 2-2 4-4

  foo

  BAR

  baz

  QUX

Set up the config with two simple fixers: one that fixes specific line ranges,

and one that always fixes the whole file. They both "fix" files by converting

letters to uppercase. They use different file extensions, so each test case can

choose which behavior to use by naming files.

  $ cat >> $HGRCPATH <<EOF

  > [extensions]

  > fix =

  > [experimental]

  > evolution.createmarkers=True

  > evolution.allowunstable=True

  > [fix]

  > uppercase-whole-file:command="$PYTHON" $UPPERCASEPY all

  > uppercase-whole-file:pattern=set:**.whole

  > uppercase-changed-lines:command="$PYTHON" $UPPERCASEPY

  > uppercase-changed-lines:linerange={first}-{last}

  > uppercase-changed-lines:pattern=set:**.changed

  > EOF

Help text for fix.

  $ hg help fix

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

  rewrite file content in changesets or working directory

      Runs any configured tools to fix the content of files. 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 revisions are specified with --rev, those revisions will be checked,

      and they may be replaced with new revisions that have fixed file content.

      It is desirable to specify all descendants of each specified revision, so

      that the fixes propagate to the descendants. If all descendants are fixed

      at the same time, no merging, rebasing, or evolution will be required.

      If --working-dir is used, files with uncommitted changes in the working

      copy will be fixed. If the checked-out revision is also fixed, the working

      directory will update to the replacement revision.

      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.

  (use 'hg help -e fix' to show help for the fix extension)

  options ([+] can be repeated):

      --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

   -w --working-dir  fix the working directory

      --whole        always fix every line of a file

  (some details hidden, use --verbose to show complete help)

  $ hg help -e fix

  fix extension - rewrite file content in changesets or working copy

  (EXPERIMENTAL)

  Provides a command that runs configured tools on the contents of modified

  files, writing back any fixes to the working copy or replacing changesets.

  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

  The :pattern suboption determines which files will be passed through each

  configured tool. See 'hg help patterns' for possible values. 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

      valueof 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.

  list of commands:

   fix           rewrite file content in changesets or working directory

  (use 'hg help -v -e fix' to show built-in aliases and global options)

There is no default behavior in the absence of --rev and --working-dir.

  $ hg init badusage

  $ cd badusage

  $ hg fix

  abort: no changesets specified

  (use --rev or --working-dir)

  [255]

  $ hg fix --whole

  abort: no changesets specified

  (use --rev or --working-dir)

  [255]

  $ hg fix --base 0

  abort: no changesets specified

  (use --rev or --working-dir)

  [255]

Fixing a public revision isn't allowed. It should abort early enough that

nothing happens, even to the working directory.

  $ printf "hello\n" > hello.whole

  $ hg commit -Aqm "hello"

  $ hg phase -r 0 --public

  $ hg fix -r 0

  abort: can't fix immutable changeset 0:6470986d2e7b

  [255]

  $ hg fix -r 0 --working-dir

  abort: can't fix immutable changeset 0:6470986d2e7b

  [255]

  $ hg cat -r tip hello.whole

  hello

  $ cat hello.whole

  hello

  $ cd ..

Fixing a clean working directory should do nothing. Even the --whole flag

shouldn't cause any clean files to be fixed. Specifying a clean file explicitly

should only fix it if the fixer always fixes the whole file. The combination of

an explicit filename and --whole should format the entire file regardless.

  $ hg init fixcleanwdir

  $ cd fixcleanwdir

  $ printf "hello\n" > hello.changed

  $ printf "world\n" > hello.whole

  $ hg commit -Aqm "foo"

  $ hg fix --working-dir

  $ hg diff

  $ hg fix --working-dir --whole

  $ hg diff

  $ hg fix --working-dir *

  $ cat *

  hello

  WORLD

  $ hg revert --all --no-backup

  reverting hello.whole

  $ hg fix --working-dir * --whole

  $ cat *

  HELLO

  WORLD

The same ideas apply to fixing a revision, so we create a revision that doesn't

modify either of the files in question and try fixing it. This also tests that

we ignore a file that doesn't match any configured fixer.

  $ hg revert --all --no-backup

  reverting hello.changed

  reverting hello.whole

  $ printf "unimportant\n" > some.file

  $ hg commit -Aqm "some other file"

  $ hg fix -r .

  $ hg cat -r tip *

  hello

  world

  unimportant

  $ hg fix -r . --whole

  $ hg cat -r tip *

  hello

  world

  unimportant

  $ hg fix -r . *

  $ hg cat -r tip *

  hello

  WORLD

  unimportant

  $ hg fix -r . * --whole --config experimental.evolution.allowdivergence=true

  2 new content-divergent changesets

  $ hg cat -r tip *

  HELLO

  WORLD

  unimportant

  $ cd ..

Fixing the working directory should still work if there are no revisions.

  $ hg init norevisions

  $ cd norevisions

  $ printf "something\n" > something.whole

  $ hg add

  adding something.whole

  $ hg fix --working-dir

  $ cat something.whole

  SOMETHING

  $ cd ..

Test the effect of fixing the working directory for each possible status, with

and without providing explicit file arguments.

  $ hg init implicitlyfixstatus

  $ cd implicitlyfixstatus

  $ printf "modified\n" > modified.whole

  $ printf "removed\n" > removed.whole

  $ printf "deleted\n" > deleted.whole

  $ printf "clean\n" > clean.whole

  $ printf "ignored.whole" > .hgignore

  $ hg commit -Aqm "stuff"

  $ printf "modified!!!\n" > modified.whole

  $ printf "unknown\n" > unknown.whole

  $ printf "ignored\n" > ignored.whole

  $ printf "added\n" > added.whole

  $ hg add added.whole

  $ hg remove removed.whole

  $ rm deleted.whole