fix: run fixer tools in the repo root as cwd so they can use the working copy
This lets fixer tools do things like find configuration files, with the caveat
that they'll only see the version of that file in the working copy, regardless
of what revisions are being fixed.
Differential Revision: https://phab.mercurial-scm.org/D6440
--- a/hgext/fix.py Thu Aug 01 22:03:52 2019 +0530
+++ b/hgext/fix.py Wed May 22 16:22:06 2019 -0700
@@ -102,6 +102,13 @@
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.
+
+Fixer tools are run the in 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 should always write fixed
+file content back to stdout as documented above.
"""
from __future__ import absolute_import
@@ -232,7 +239,7 @@
for rev, path in items:
ctx = repo[rev]
olddata = ctx[path].data()
- metadata, newdata = fixfile(ui, opts, fixers, ctx, path,
+ metadata, newdata = fixfile(ui, repo, opts, fixers, ctx, path,
basectxs[rev])
# Don't waste memory/time passing unchanged content back, but
# produce one result per item either way.
@@ -529,7 +536,7 @@
basectxs[rev].add(pctx)
return basectxs
-def fixfile(ui, opts, fixers, fixctx, path, basectxs):
+def fixfile(ui, repo, opts, fixers, fixctx, path, basectxs):
"""Run any configured fixers that should affect the file in this context
Returns the file content that results from applying the fixers in some order
@@ -538,7 +545,8 @@
(i.e. they will only avoid lines that are common to all basectxs).
A fixer tool's stdout will become the file's new content if and only if it
- exits with code zero.
+ exits with code zero. The fixer tool's working directory is the repository's
+ root.
"""
metadata = {}
newdata = fixctx[path].data()
@@ -552,7 +560,7 @@
proc = subprocess.Popen(
procutil.tonativestr(command),
shell=True,
- cwd=procutil.tonativestr(b'/'),
+ cwd=repo.root,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
--- a/tests/test-fix.t Thu Aug 01 22:03:52 2019 +0530
+++ b/tests/test-fix.t Wed May 22 16:22:06 2019 -0700
@@ -215,6 +215,13 @@
executions that modified a file. This aggregates the same metadata
previously passed to the "postfixfile" hook.
+ Fixer tools are run the in 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 should always write
+ fixed file content back to stdout as documented above.
+
list of commands:
fix rewrite file content in changesets or working directory
@@ -1269,6 +1276,41 @@
$ cd ..
+We run fixer tools in the repo root so they can look for config files or other
+important things in the working directory. This does NOT mean we are
+reconstructing a working copy of every revision being fixed; we're just giving
+the tool knowledge of the repo's location in case it can do something
+reasonable with that.
+
+ $ hg init subprocesscwd
+ $ cd subprocesscwd
+
+ $ cat >> .hg/hgrc <<EOF
+ > [fix]
+ > printcwd:command = pwd
+ > printcwd:pattern = path:foo/bar
+ > EOF
+
+ $ mkdir foo
+ $ printf "bar\n" > foo/bar
+ $ hg commit -Aqm blah
+
+ $ hg fix -w -r . foo/bar
+ $ hg cat -r tip foo/bar
+ $TESTTMP/subprocesscwd
+ $ cat foo/bar
+ $TESTTMP/subprocesscwd
+
+ $ cd foo
+
+ $ hg fix -w -r . bar
+ $ hg cat -r tip bar
+ $TESTTMP/subprocesscwd
+ $ cat bar
+ $TESTTMP/subprocesscwd
+
+ $ cd ../..
+
Tools configured without a pattern are ignored. It would be too dangerous to
run them on all files, because this might happen while testing a configuration
that also deletes all of the file content. There is no reasonable subset of the