We refuse to pick a destination for a bare 'hg merge' if the working copy is not
at head. This is meant to prevent strange merge from user who forget to update.
(Moreover, such merge does not reduce actually the number of heads)
However, we were doing that as the last possible failure type. So user were
recommended to merge with an explicit head (from this bad location) if the
branch had too many heads.
We now make "not on branch heads" class of failure the first things to check
and fail on. The one test that change was actually trying to check for these
failure (and did not). The new test output is correct.
As we will make 'rebase' behave more like 'merge', it will no longer pick
'max(branch(.))' as the default destination. We have to hard code the expected
destination is multiple tests where it matters. After a careful inspection none
of theses tests really cares about the default destination behavior and just
omitted one out of laziness.
These tests do not care about that extra branch at all. In future changeset we
will make rebase behave like merge and abort in case of an ambiguous destination
(eg: multiple other heads) and that extra branch will make the command
invocation breaks.
We preventively remove this extra branch from the relevant tests in an
independant changeset to reduce noise and increase confidence in the final
change.
If the executable is not named as "hg", TTest runner inserts alias. This
way, we can run tests with chg. But it is still warned because the alias
does not always work. We do "$BINDIR"/hg in a few places.
An external extension whose docstring doesn't conform to Mercurial standards
used to cause crashes. Test that we omit such extensions when you do a
keyword search.
This helps the test to pass with hgwatchman, which would otherwise need to be
taught about a nested .hg directory. hgwatchman already blacklists
test-nested-repo.t which covers the actual usecase
Currently, whitespace in command line --config options are considered
significant while whitespace in config files are not considered
significant. This diff strips the leading and trailing whitespace from
command line config options.
This matches 'hook failed' warnings.
We're also going to add hints to some of the hook load errors. Without this
change we'd have two pairs of parens for a single error message, which looks
really cluttered.
Previously, two changes that were nearly, but not quite, identical would result
in large merge conflict regions that looked very similar, and were thus very
confusing to users, and lead people used to other source control systems to
claim that "mercurial's merge algorithms suck". In the relatively common case
of a new file being introduced in two branches with very slight modifications,
the old behavior would show the entire file as a conflict, and it would be very
difficult for a user to determine what was going on.
In the past, mercurial attempted to solve this with a "very smart" algorithm
that would find all common lines, but this has significant problems as
described in 3d22d20aa950.
Instead, we use a "very dumb" algorithm introduced in the previous patch that
simply matches lines at the periphery of conflict regions. This minimizes most
conflict regions well, though there may still be some degenerate edge cases,
like small modification to the beginning and end of a large file.
Bare 'hg update' now brings you to the tipmost descendant (on the same branch).
Leaving the user on the same topological branch. The previous behavior, updating
to the tipmost changeset on the same branch could lead to jump from a
topological branch to another. This was confusing and impractical. As the only
conceivable reason for the old behavior have been address by the recently
introduce message about other heads, we can "safely" change this behavior
All test changes have been reviewed and seen a valid consequences.
The --update is unrelated to the test and has no effect as it fails anyway.
Dropping it reduces the noise in the coming change in default destination for
update.
With an ignore pattern containing a '/' and a Windows style path containing '\',
status was properly ignoring the file, but debugignore was stating that it
wasn't ignored.
This rule detects "hg extdiff" invocation without -p/--program and
-o/--option.
This patch specifies "-p diff" explicitly in test-extdiff.t to avoid
false positive matching.
Before this patch, some tests using external "diff" command via
extdiff extension fail on Solaris, because of incompatibility of
"diff" command and its output.
For example, system standard "diff" (= /usr/bin/diff) on Solaris
differs from GNU diff in points below:
- "-N" (treat absent files as empty) option isn't supported
- files are examined not in dictionary order
(maybe, in order in storage)
This patch introduces portable diff script "pdiff" and make tests use
it via extdiff extension.
For portability of tests, this patch invokes "pdiff" script with
explicit "sh", because standard shell of runtime platform ("cmd.exe"
on Windows) is used at first to invoke external diff command.
With -n/--test and if the PAGER environment variable is set, 'hg email' send its
output to the user defined pager.
If the pager capture the output, the test is unable verify it.
Unsetting the PAGER environment variable force 'hg email' to write to stdout.
This is fixing for 'legacy exception syntax; use "as" instead of ","'
check-code rule.
check-code has overlooked these, because files aren't recognized as
one to be checked (this problem is fixed by subsequent patch).
This is fixing for 'legacy octal syntax; use "0o" prefix instead of
"0"' check-code rule.
check-code has overlooked this, because a file isn't recognized as one
to be checked (this problem is fixed by subsequent patch).
This is fixing for 'missing whitespace in expression' check-code rule.
check-code has overlooked this, because a file isn't recognized as one
to be checked (this problem is fixed by subsequent patch).
Before this patch, some tests using external "diff" command via
extdiff extension fail on Solaris, because system standard "diff" (=
/usr/bin/diff) on Solaris always generates chunk headers below:
- "@@ -1,0 +1,nnnn @@" for added file
- "@@ -1,nnnn +1,0 @@" for removed file
even though "diff" on Linux generates:
- "@@ -0,0 +1,nnnn @@" for added file
- "@@ -1,nnnn +0,0 @@" for removed file
This patch makes chunk header of external diff glob-ed for portability
of tests.
"hg diff" output follows Linux style, and there are many such diff
output lines in existing tests. This is reason why this patch doesn't
add check-code.py any rule to detect such diff output in tests.
This patch is a part of making tests using external "diff" portable,
and test-subrepo-deep-nested-change.t isn't yet portable even after
this patch.
Before this patch, some tests using external "diff" command via
extdiff extension fail on Solaris, because system standard "diff" (=
/usr/bin/diff) on Solaris always formats chunk header in the style
below:
@@ -X.x +Y.y @@
even though "diff" on Linux sometimes omits ".x" and/or ".y" in it.
This patch makes chunk header of external diff glob-ed for portability
of tests, and adds check-code.py rules to detect such diff output in
tests.
This patch also changes "hg diff" output in test-subrepo-git to
simplify detection rules, even though it is certainly portable because
these lines are generated by "git" command.
This patch is a part of making tests using external "diff" portable,
and tests below aren't yet portable even after this patch.
test-largefiles-update.t
test-subrepo-deep-nested-change.t
Before this patch, some tests using external "diff" command via
extdiff extension fail on Solaris, because system standard "diff" (=
/usr/bin/diff) on Solaris doesn't display timezone for timestamp of
each files in diff output.
This patch makes timezone in external diff output glob-ed for
portability of tests, and adds check-code.py a rule to detect such
Before this patch, some tests using external "diff" command via
extdiff extension fail on Solaris, because "-p" (show which C function
each change is in) option isn't supported by system standard "diff" on
Solaris, even though extdiff passes it to external "diff" by default.
Fortunately, this non-portable option isn't important for (current, at
least) tests using external "diff" command via extdiff extension.
This patch omits "-p" for external "diff" command via extdiff
extension for portability of tests, and adds check-code.py a rule to
detect invocation of "diff" with "-p".
Newly added check-code.py rule examines only lines generated by
external "diff" with "-r", because strict examination might
misidentify "hg diff -p" or other complicated lines consisting of
"diff" string as wrong one.
This patch is a part of making tests using external "diff" portable,
and tests below aren't yet portable even after this patch.
test-graft.t
test-largefiles-update.t
test-subrepo-deep-nested-change.t
When I taught debugrebuildfncache about dirlogs in ebe9dacc63ba
(treemanifests: fix streaming clone, 2016-02-04), I added a
last-minute "if 'treemanifest' in repo" guard. That should have been
checking for "... in repo.requirements". Fix that and add tests for
it.
A concern around the user experience of Mercurial is user getting stuck on there
own topological branch forever. For example, someone pulling another topological
branch, missing that message in pull asking them to merge and getting stuck on
there own local branch.
The current way to "address" this concern was for bare 'hg update' to target the
tipmost (also latest pulled) changesets and complain when the update was not
linear. That way, failure to merge newly pulled changesets would result in some
kind of failure.
Yet the failure was quite obscure, not working in all cases (eg: commit right
after pull) and the behavior was very impractical in the common case
(eg: issue4673).
To be able to change that behavior, we need to provide other ways to alert a
user stucks on one of many topological head. We do so with an extra message after
bare update:
1 other heads for branch "default"
Bookmark get its own special version:
1 other divergent bookmarks for "foobar"
There is significant room to improve the message itself, and we should augment
it with hint about how to see theses other heads or handle the situation (see
in-line comment). But having "a" message is already a significant improvement
compared to the existing situation. Once we have it we can iterate on a better
version of it. As having such message is an important step toward changing the
default destination for update and other nicety, I would like to move forward
quickly on getting such message.
This was discussed during London - October 2015 Sprint.
With util.getpid, it is now possible to define fixed pids.
Future iterations can define a map of pids on a locked
first come first serve basis to create a more realistic
harness, but for now this is good enough.
This applies to blackbox, but could apply to other
tests as well.
Without this, when there are multiple ui views, each blackbox
will have its own file handle, and the logging will be in
a really bad order.
Also, because of the way blackbox works, it never closes its
file handles, which means the last output before exit is
often lost.
While it is not easy to make a file 000 on Windows, you can
emulate most of the behaviors by replacing the file with a directory.
Also corrects test description to properly indicate that failing to
read from the log is fatal.
checkunknown and checkignored are currently respected for updates and regular
merges, but not for certain kinds of rebases. To be precise, they aren't
respected for rebases when:
(1) we're rebasing while currently on the destination commit, and
(2) an untracked or ignored file F is currently in the working copy, and
(3) the same file F is in a source commit, and
(4) F has different contents in the source commit.
This happens because rebases set force to True when calling merge.update.
Setting force to True makes a lot of sense in general, but it turns out the
force option is overloaded: there's a deprecated '--force' option in merge that
allows you to merge in outstanding changes, including changes in untracked
files. We use the 'mergeforce' parameter to tell those two cases apart.
I think the behavior during rebases when checkunknown is 'abort' (the default)
is wrong -- we should abort on or overwrite differing untracked files, not try
to merge them in. However that currently breaks rebases by aborting in the
middle -- we need better handling for that case before we can change the
default.
In an upcoming patch we're going to change the behavior of some merges with
merge.checkunknown=warn or ignore -- ensure that the behavior of the deprecated
'merge --force' remains the same.
