Most commands expands configured paths when repositories are specified, just as
the urls help says. Clone also expands the destination path. Clone is morally
equivalent to init + push/pull, so init should also expand the destination path
- and that is what this patch makes it do.
There is no really good usecases for this and in most cases it doesn't matter,
but consistency is nice, and otherwise we would have to document the exception.
This adds support to identify a particular transplanted changeset or set
of changesets. The argument is optional. Examples:
hg log -r 'transplanted(1234 or 2345)'
hg log -r 'transplanted()'
The glog command didn't emit header and footer from the style, as demonstrated
by "hg glog --style xml". Asciiart combined with xml markup hardly makes sense,
but header and footer might however be useful for adding for example html pre
tags around the graph.
parsehghaveoutput expects just the test output, not the merged test/output,
so for skipped unified tests e.g.:
Skipped test-convert-darcs.t: missing feature: irrelevant
was shown instead of:
Skipped test-convert-darcs.t: missing feature: darcs client
It seems like ln -s gets confused if an existing symlink is dangling:
$ rm -f a b; ln -s a b; ln -sf b b
ln: cannot create b: File exists
We now rely on rm instead of on ln -sf.
_bookmarks is loaded lazily and calls super.lookup(). Unfortunately, branch and
tags caches initializations also recurse in lookup() and end up trying to
access _bookmarks again. Massive confusion ensues.
I considered fixing all branches and tags cache loading to avoid recursing in
lookup() but it would add complexity to otherwise working code provided lookups
are performed on nodes or revnums.
Some callers to patchheader.qseries returned the value
further, but pathcheader.qseries does not explicitly
return anything. It was confusing this was returned
further
When using hg commands over an http repository in a long running process, a
httphandler instance is leaked for each command, because of a loop
handler.parent -> OpenerDirector and OpenerDirector.handlers -> handler which
is not handled by Python's gc. Discussion on #mercurial concluded that removing
the __del__ method solved the problem.
f02da4369319 assumed that walkchangerevs called prep with all relevant matched
filenames, but actually it only contains the names of files changed in the
relevant changeset. That meant that log diff/stat of merges missed the diff for
files only changed in the other branch.
This is a minimal fix for making sure we only use fns when we are following and
thus will have problems with merges anyway ...
--force was not necessary when passing --rev since cb494d252290, but this
behaviour is usually harmful when branch names are passed instead of explicit
revisions.
