The Python 'is' operator compares object identity, so it should
definitely not be applied to string or number literals, which Python
implementations are free to represent with a temporary object.
This should catch the following kinds of bogus expressions (examples):
x is 'foo' x is not 'foo'
x is "bar" x is not "bar"
x is 42 x is not 42
x is -36 x is not -36
As originally proposed by Martin Geisler, amended with catching
negative numbers.
This patch adds a case to test-hardlinks.t which demonstrates that
hardlinks in the working directory are broken up (using 'hg update').
Motivation for this patch:
'hg help clone' shows copying repositories *and* the working directory
using 'cp -al', creating hardlinks in the *working directory* too (not
just in the store).
Note that we can't use 'cp -al' since for example MacOS X doesn't
support these options on cp. I'm thus using the same trick as in
test-hardlinks-safety.t for creating hardlinks in the working dir.
Regression from 9f0026001bfd. That previous commit is not supposed
to affect log calls without --follow, so we step out of this
codepath if follow is not True, and it's enough to fix the
regression.
When --follow is given, we fix the issue by taking into account
changesets that have a rev > maxrev to build the filegraph: even if
those files are not included in the final result, it's still needed
to walk correctly the graph from the end of the filelog to minrev, to
track accurately renames.
While this situation should never under normal use, some real
life repos sometimes contain such changesets (older hg versions,
broken rebases, etc...)
hgweb was displaying an "Internal error" in this case, and graphlog
displayed a redundant branch all the way to null: it does not cost us
much to just ignore this extra parent when constructing the DAG.
We were not returning the correct result if nullrev was in revs, as we
are checking parent(currentrev) != nullrev before yielding currentrev
test-convert-hg-startrev was wrong: if we start converting from rev -1 and
onwards, all the descendants of -1 (full repo) should be converted.
This makes test output less ambiguous.
Failing test output will be escaped and marked up if necessary. A Python
string-escape compatible encoding is used, but not everything is encoded -
especially not \n and \t and '.
Output chunks without a trailing LF will now work but get (no-eol) appended.
This change mostly moves code around so we can handle that an output line
starts with data from previous command, followed by salt and the next command.
203ffed27f86 made this simple test-test.t succeed silently:
$ printf ' $ true' > test-test.t
but did not give a usable .err in this case:
$ printf ' $ false' > test-test.t
The missing LF will now be fixed in the test output and it will thus give a
test failure and a solution in the .err file.
This enables minirst to parse and print option lists which have both
long and short options. Before, we could only parse option lists with
long options.
When --debug is given to the test runner, run() returns (retcode, None).
Do not try to use None output as a string, and return directly, similarly
as other testers.
With this patch applied, Mercurial will list the hashes of new remote heads
if push --debug aborts because of new remote heads (option -f/--force not set).
Example:
$ hg push --debug repo1
using http://example.org/repo1
http auth: user johndoe, password not set
sending between command
pushing to http://example.org/repo1
sending capabilities command
capabilities: changegroupsubset stream=1 lookup pushkey unbundle=HG10GZ,HG10BZ,HG10UN branchmap
sending heads command
searching for changes
common changesets up to 187dd3f0a37d
sending branchmap command
new remote heads on branch 'default' <- new output line
new remote head 5862c07f53a2 <- new output line
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
Compare to without --debug (not changed by this patch, including it here
for reference purposes only):
$ hg push repo1
pushing to http://example.org/repo1
searching for changes
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
Motivation for this change:
'hg outgoing' may list a whole lot of benign changesets plus an odd changeset
that will trigger the "new remote heads" abort. It can be hard to spot that
single unwanted changeset (it may be an old forgotten experiment, lingering
in the local repo).
"hg log -r 'heads(outgoing())'" might be useful, but that also lists a head
that may be benign on push.
Inside prepush(), we already know which heads are causing troubles on 'hg push'.
Why not make that info available (at least on --debug)?
This would also be helpful for doing remote support, as the supporter can ask
the user to paste the output of 'hg push --debug' on error and then ask further
questions about the heads listed.
- Handle 'subset' argument
- Stop returning the null rev from p1 and parents, as in the non-dirstate case
- Order parents as in the non-dirstate case (ascending revs)