transplant

transplant changesets from another branch:

hg transplant [-s REPO] [-b BRANCH [-a]] [-p REV] [-m REV] [REV]...

Selected changesets will be applied on top of the current working directory with the log of the original changeset. The changesets are copied and will thus appear twice in the history with different identities.

Consider using the graft command if everything is inside the same repository - it will use merges and will usually give a better result. Use the rebase extension if the changesets are unpublished and you want to move them instead of copying them.

If --log is specified, log messages will have a comment appended of the form:

(transplanted from CHANGESETHASH)

You can rewrite the changelog message with the --filter option. Its argument will be invoked with the current changelog message as $1 and the patch as $2.

--source/-s specifies another repository to use for selecting changesets, just as if it temporarily had been pulled. If --branch/-b is specified, these revisions will be used as heads when deciding which changesets to transplant, just as if only these revisions had been pulled. If --all/-a is specified, all the revisions up to the heads specified with --branch will be transplanted.

Example:

• transplant all changes up to REV on top of your current revision:

  hg transplant --branch REV --all
  

You can optionally mark selected transplanted changesets as merge changesets. You will not be prompted to transplant any ancestors of a merged transplant, and you can merge descendants of them normally instead of transplanting them.

Merge changesets may be transplanted directly by specifying the proper parent changeset by calling hg transplant --parent.

If no merges or revisions are provided, hg transplant will start an interactive changeset browser.

If a changeset application fails, you can fix the merge by hand and then resume where you left off by calling hg transplant --continue/-c.

Options:

-s, --source <REPO>
	transplant changesets from REPO
-b, --branch <REV[+]>
	use this source changeset as head
-a, --all	pull all changesets up to the --branch revisions
-p, --prune <REV[+]>
	skip over REV
-m, --merge <REV[+]>
	merge at REV
--parent <REV>	parent to choose when transplanting merge
-e, --edit	invoke editor on commit messages
--log	append transplant info to log message
--stop	stop interrupted transplant
-c, --continue	continue last transplant session after fixing conflicts
--filter <CMD>	filter changesets through command

[+] marked option can be specified multiple times