Also restructures the mode determination as discussed on IRC.
I tried to simplify the code too, while keeping the original
semantics except for the case of --color=always.
It's desirable to run some tests all the time, for example
test-check-pyflakes.t and test-check-code-hg.py. This allows passing
--whitelist as a path to a file (flag can be specified more than once)
which contains a list of files to whitelist. Whitelisted tests are run
even if they're blacklisted or wouldn't match a --keyword test
run. For example, to do a quick test of usehttp2, one can now do
$ cat > test-whitelist <<EOF
> test-check-pyflakes.t
> test-check-code-hg.py
> EOF
$ (cd tests && ./run-tests.py --extra-config-opt 'ui.usehttp2=true'
> -k http -j 8 --whitelist test-whitelist)
and have all http-specific tests run as well as the two code linters.
This includes all affected files, so it can be used for an extended view of
the files or as a replacement for the filenodelink and filenolink templates.
Previously, pull would not update if new branch heads were received,
whereas pull && update would move to the tipmost branch head.
Also change the "crosses branches" abort in merge.update from
"crosses branches (merge branches or use --check to force update)"
to
"crosses branches (merge branches or update --check to force update)"
since it can no longer assume the user is running hg update.
The internal list representation of guards was leaking into the
output. The guards were always printed using repr(guard) and that
style was kept.
When "hg qguard -l" prints several guards for a patch, it does so by
joining the names with " " and that style was used for the error
messages too.
workingctx.remove(list, unlink=True) is unsuited here, because it does too
much: it also unlinks added files. But the command 'hg remove' is specified
to *never* unlink added files.
Instead, we now unlink the files at the commands.remove level (if --after was
not specified) and use workingctx.forget for all files.
As an added bonus, this happens to eliminate a wlock acquire/release pair,
since the previous implementation caused
acquire wlock
release wlock
acquire wlock
release wlock
where the first pair of acquire/release was caused by the workingctx.forget
call, and the second by the workingctx.remove call.
Without the blank line, the minirst parser renders
Term-1
Line-1
Line-2
Term-2
Line-1
as
Term-1
Line-1
Line-2 Term-2 Line-1
because the second term is seen as a paragraph.
git patches may require copies to be handled out-of-order. For instance, take
the following sequence:
* modify a
* copy a into b
Here, we have to generate b from a before its modification. To do so,
applydiff() was scanning for copy metadata and performing the copies before
processing the other changes in-order. While smart and efficient, this approach
complicates things by handling file copies and file creations at different
places and times. While a new file must not exist before being patched a copied
file already exists before applying the first hunk.
Instead of copying the files at their final destination before patching, we
store them in a temporary file location and retrieve them when patching. The
filestore always stores file content in real files but nothing prevents adding
a cache layer. The filestore class was kept separate from fsbackend for at
least two reasons:
- This class is likely to be reused as a temporary result store for a future
repository patching call (entries just have to be extended to contain copy
sources).
- Delegating this role to backends might be more efficient in a repository
backend case: the source files are already available in the repository itself
and do not need to be copied again. It also means that third-parties backend
would have to implement two other methods. If we ever decide to merge the
filestore feature into backend, a minimalistic approach would be to compose
with filestore directly. Keep in mind this copy overhead only applies for
copy/rename sources, and may even be reduced to copy sources which have to
handled ahead of time.
The patcher has to know if a file is being created or removed to check if the
target already exists, or to actually unlink the file when a hunk emptying it
is applied. This was done by embedding the creation/removal information in the
first (and only) hunk attached to the file.
There are two problems with this approach:
- creation/removal is really a property of the file being patched and not its
hunk.
- for regular patches, file creation cannot be deduced at parsing time: there
are case where the *stripped* file paths must be compared. Modifying hunks
after their creation is clumsy and prevent further refactorings related to
copies handling.
Instead, we delegate this job to selectfile() which has all the relevant
information, and remove the hunk createfile() and rmfile() methods.
