Problem:
getremotechanges would return the 'other' repo if nothing was incoming and
there thus wasn't any bundle to base the repo on. The 'other' could be a http
peer which only implement the functionality available over the http protocol.
Transplant could thus fail with
TypeError: argument of type 'httppeer' is not iterable
Solution:
Return the local repo instead of the remote peer if there is no reason to place
a bundlerepo on top of the local repo.
If patch.patch() reports patched files when applying a changeset and the
following commit says nothing changed, transplant used to abort with a
RuntimeError, assuming something went wrong with patching.
The mismatch is patch.patch() reports patched files, not changed ones.
It could be modified to report changed files but it means duplicating
work from status, may be expensive in the case of binary files, and is
probably not that useful at API level. For instance, if two patches are
applied on the working directory, the outcome may be nothing changed
while each call would have returned modified files. The caller would
have to call status() itself again.
This patch fixes the issue by trusting patching code: if the patch
succeeded and commit reports nothing changed, then nothing changed,
patch() did not "dropped changes on the floor".
This predicate is used to find csets that were created because of a graft,
transplant or rebase --keep. An optional revset can be supplied, in which case
the result will be limited to those copies which specified one of the revs as
the source for the command.
hg log -r destination() # csets copied from anywhere
hg log -r destination(branch(default)) # all csets copied from default
hg log -r origin(x) or destination(origin(x)) # all instances of x
This predicate will follow a cset through different types of copies. Given a
repo with a cset 'S' that is grafted to create G(S), which itself is
transplanted to become T(G(S)):
o-S
/
o-o-G(S)
\
o-T(G(S))
hg log -r destination( S ) # { G(S), T(G(S)) }
hg log -r destination( G(S) ) # { T(G(S)) }
The implementation differences between the three different copy commands (see
the origin() predicate) are not intentionally exposed, however if the
transplant was a graft instead:
hg log -r destination( G(S) ) # {}
because the 'extra' field in G(G(S)) is S, not G(S). The implementation cannot
correct this by following sources before G(S) and then select the csets that
reference those sources because the cset provided to the predicate would also
end up selected. If there were more than two copies, sources of the argument
would also get selected.
Note that the convert extension does not currently update the 'extra' map in its
destination csets, and therefore copies made prior to the convert will be
missing from the resulting set.
Instead of the loop over 'subset', the following almost works, but does not
select a transplant of a transplant. That is, 'destination(S)' will only
select T(S).
dests = set([r for r in subset if _getrevsource(repo, r) in args])
Some tests ended up in a directory several directories deeper than $TESTTMP,
usually because some 'cd ..' had been forgotten between different test cases.
Add 'cd ..' where they are missing so the tests get back where they started.
Otherwise, all transplanted revisions are gone and the failing one cannot be
fixed (unless it is the first one).
I do not know what is the expected behaviour with rollback, probably something
pull-like. Non-conflicting cases should work as previously. But something like:
$ hg transplant r1 r2
commiting r1 as c1
failing r2
$ hg transplant --continue
committing r2 as c2
$ hg rollback
would reset the repository to its state before the "transplant --continue"
instead of the whole transplant session. To fix this we might need a way to
open an existing journal file, not sure this is worth the pain.
This change permits the transplant extension to operate on merge
changesets by way of --parent. This is particularly useful for
workflows which cherrypick branch merges rather than each commit
within a branch.
When issuing `hg pull -r REV` in a repo with no common ancestor with the
remote repo, the message 'requesting all changes' is printed, even though only
the changese that are ancestors of REV are actually requested. This can be
confusing for users (see
http://www.selenic.com/pipermail/mercurial/2010-October/035508.html).
This silences the message if (and only if) the '-r' option was passed.
This adds a " (glob)" marker that works like a simpler version of
(re): "*" is converted to ".*", and "?" is converted to ".".
Both special characters can be escaped using "\", and the backslash
itself can be escaped as well.
Other glob-style syntax, like "**", "[chars]", or "[!chars]", isn't
supported.
Consider this test:
$ hg glog --template '{rev}:{node|short} "{desc}"\n'
@ 2:20c4f79fd7ac "3"
|
| o 1:38f24201dcab "2"
|/
o 0:2a18120dc1c9 "1"
Because each line beginning with "|" can be compiled as a regular
expression (equivalent to ".*|"), they will match any output.
Similarly:
$ echo foo
The blank output line can be compiled as a regular expression and will
also match any output.
With this patch, none of the above output lines will be matched as
regular expressions. A line must end in " (re)" in order to be matched
as one.
Lines are still matched literally first, so the following will pass:
$ echo 'foo (re)'
foo (re)
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.
Sometimes it is necessary to know the original revision ID in order to
correctly rewrite the patch or commit message when transplanting. This
patch follows the pattern set by the existing 'HGUSER' environment variable,
and adds a test that covers both HGUSER and HGREVISION.