We've been talking for years about a one-stop config knob to opt in to
better behavior. There have been a lot of ideas thrown around, but
they all seem to be too complicated to get anyone to actually do the
work.. As such, this patch is the stupidest thing that can possibly
work in the name of getting a good feature to users.
Right now it's just three config settings that I think are generally
uncontroversial, but I expect to add more soon. That will likely
include adding new config knobs for the express purpose of adding them
to tweakdefaults.
When the config is set to true, status output becomes relative to the
working directory. This has bugged me since I started using hg and it
turns it is sillily simple to support it (unless I missed something,
of course).
We could also add a --relative flag, but I would personally always
want that on, and I haven't heard any use for having it sometimes on,
so this patch only lets you enable it via config.
This patch includes addition of absolute_import and print_function to the
files where they are missing. The modern importing conventions are also followed.
Before, copied files were assumed as "A" (added) and listed followed by
non-copy added files. This could double entries of a copy if it had "M"
(modified) state.
So, this patch makes the template check if a file is included in copies dict.
This way, entries should never be doubled.
The output of "log -Tstatus -C" does not always agree with "status -C --change"
due to the bug of "status", which is documented in test-status.t. See also
21a68fa3c757.
This backs out 7e679fd51132 (status: change + back out == clean (API),
2016-01-04). Although correct, it turned out that it was just too
slow. For example, 'hg status --rev .~1000 --rev .' on the Mozilla
repo went from <1s to >30s on cold disk. So we go back to reporting
reverted changes as modified instead of clean. These are rare anyway,
as suggested by the fact that it had been broken since before
Mercurial 2.0.
The preceding #if conditional was the only modification to the file, so the
"reverting file" line in the subsequent revert command was getting dropped.
After backing out a change, so the file contents is equal to a
previous revision of itself, we currently report the status between
the two equal revisions as modified. This is because
context._buildstatus() reports any file whose new nodeid is not equal
to _newnode as modified. That magic nodeid is given only to files
added or modified in the working directory, so any file whose nodeid
has changed between two revisions will be reported as modified.
Fix by simply comparing the file contents for all cases where the
nodeid changed, whether they are in the working copy or committed.
Marking with (API) as it subtly changes the semantics of the method.
After just changing the flag on a file, plain 'hg status' will report
the file as modified. However, after reverting a file to a previous
revision's state and changing the flag, it will be reported as clean.
Fix by comparing the flags that were previously ignored in
context._buildstatus().
The main purpose of wdir() is to annotate working-directory files.
Currently many commands and revsets cannot handle workingctx and may raise
exception. For example, -r ":wdir()" results in TypeError. This problem will
be addressed by future patches.
We could add "wdir" symbol instead, but it would conflict with the existing
tag, bookmark or branch. So I decided not to.
List of commands that will potentially support workingctx revision:
command default remarks
-------- ------- -----------------------------------------------------
annotate p1 useful
archive p1 might be useful
cat p1 might be useful on Windows (no cat)
diff p1:wdir (default)
export p1 might be useful if wctx can have draft commit message
files wdir (default)
grep tip:0 might be useful
identify wdir (default)
locate wdir (default)
log tip:0 might be useful with -p or -G option
parents wdir (default)
status wdir (default)
This patch includes minimal test of "hg status" that should be able to handle
the workingctx revision.
The result of 'hg rm' + 'hg rename' disagreed with the one from
'hg rename --force'. We align them on 'hg move --force' because it agrees with
what 'hg status' says after the commit.
Stopping reporting a modified file as added puts an end to the hg revert confusion in this
situation (issue4458).
However, reporting the file as modified also prevents revert from restoring the copy
source. We fix this in a later changeset.
Git diff also stop reporting the add in the middle of the chain as add. Not
sure how important (and even wrong) it is.
The 'status --rev' code is not very well tested, which has bitten us
as recently as in issue4321. Let's add some more tests, some of which
uncover bugs. Remove the few existing tests that are now covered in a
more thorough and consistent way.
By the magic of code movement, we ended up dropping unknown and ignored
information when comparing the working directory with a non-parent revision.
Let's stop doing it and add a test.
In Mercurial 3.0, "hg status" can list the same file twice if it was removed
but still exists in working directory, i.e. removed by "hg forget":
$ hg status --rev 0 removed
R removed
? removed
But since 64d05ea3a10f, untracked state, "?", is no longer displayed in this
example.
I think the new behavior is correct since a file should have single state, but
if it is a bug, this patch should be dropped.
The fall-back root for walking is the repo root, not no root.
The "roots" do however also end up in m.files() which is used in various ways,
for instance to indicate whether matches are exact. The change could thus have
other impacts.
when pattern which does not match against any files in working context
is specified, current implementation of 'localrepository.status()'
decides whether warning message about it should be shown or not by
'f not in context'
this works correctly for 'file pattern', but not for 'directory
pattern', because 'f not in context' always returns True for
directories, even if they are related to the context.
this patch uses 'changectx.dirs()' to examine whether specified
pattern is related to the context as a directory or not.
printf on AIX default shell ksh (89) says \1 is an invalid escape. It insists
on at least 2 digits. This causes failures in test-keyword.t and test-status.t.
check-code.py already looks out for \NNN and recommends using Python
for outputting octal values. Extend the check to \NN and \N and fix up
resulting failures.
If file data starts with '\1\n', it will be escaped in the revlog to
create an empty metadata block, thus adding four bytes to the size in
the revlog size index. There's no way to detect that this has happened
in filelog.size() faster than decompressing each revision [1].
For filectx.cmp(), we have the size of the file in the working directory
available. If it differs by exactly four bytes, it may be this case, so
do a full comparison.
[1]: http://markmail.org/message/5akdbmmqx7vq2fsg
All tests repeatedly passes with a3900c75ca8c on some machines, but on other
machines it regularly causes failure in test-mv-cp-st-diff.t, such as:
@@ -203,6 +203,7 @@
- working to root: --rev 0
M a
+ M x/x
A b
a
The manifest value of a file will never be false when "not parentworking", and
the expensive content comparision would thus fortunately never be reached. (If
it was reached it would be wrong for example in case of renames.)
This code once handled status against working directory, but that has been done
elsewhere for a long time.
Many tests fixed the commit date of their changesets at '1000000 0' or
similar. However testing with "Mon Jan 12 13:46:40 1970 +0000" is not
better than testing with "Thu Jan 01 00:00:00 1970 +0000", which is
the default run-tests.py installs.
Removing the unnecessary flag removes some clutter and will hopefully
make it clearer what the tests are really trying to test. Some tests
did not even change their output when the dates were changed, in which
case the -d flag was truly irrelevant.
Dates used in sequence (such as '0 0', '1 0', etc...) were left alone
since they may make the test easier to understand.
