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.
