Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

pull files from a specific revision - mercurial

Tags:

mercurial

I have 3 repositories, each created with the same code base but different enough to warrant different repositories. My "dream" work flow would be to do work in the development repository and then pull these changes into the other repositories. I know I can do this with something like:

hg pull -r X -f repo

but this will give me all changesets up to X. Is it possible to just pull all the changesets from a specific revision or even from a range of revisions?

like image 749
mdonovan2010 Avatar asked Oct 17 '10 17:10

mdonovan2010


People also ask

How do you pull in Mercurial?

Pull changes from the Mercurial upstream (Pull)From the main menu, choose Hg | Mercurial | Pull. Specify the required URL address of the source remote repository.

How do I revert a file in Mercurial?

To revert a file to a specific changeset, use hg revert -r CHANGESET FILENAME . This will revert the file without committing it.

How do I Untrack a file in Mercurial?

Mercurial offers a combination command, hg addremove , that adds untracked files and marks missing files as removed. The hg commit command also provides a -A option that performs this same add-and-remove, immediately followed by a commit.


2 Answers

There is no good way to cherry pick revisions in mercurial (that's what your proposed workflow is called). There are some not-so-great ways to do it: export+import (or the convenience wrapper around export+import called transplant), but the draw back there is you have the same changeset with different hashes in multiple repositories, with no good way to represent that if/when you try to move changes across again.

Better is to modify your workflow so that when you want to move over a change you're okay with moving over all of its ancestors, and you do this by consciously picking a changeset's ancestors.

For example, if you're fixing a bug that's in the development repository, and all three "other" repositories don't just change the change's parent revision the tip of the development repository. First do a hg update -r THE_REVISION_WHERE_THE_BUG_WAS_ADDED, then fix your bug, and then commit. You'll see a message saying new head created, which is expected.

Now you'd got that fix as a changesets whose only parent is the changeset in which the bug was introduced -- which must exist in the 3 other repositories or they wouldn't have the bug. So now you can pull that new changeset into the "3" other repositories without bringing everything else in development with them. And then you do a quick hg merge in each of those four repositories blending the bug fix into their deployable tip.

Getting a handle of how to structure repositories with common functionality but customizations in each, can be a little tricky, but if you structure things right you can do all of your intra-repo migrations using using push, pull, and merge, and never have to fix a bug twice, have the same code in different changesets, or re-do a repository's customization.

As a note, the bisect command, does a great job of answering the "where was this bug introduced" question before one starts fixing it.

like image 125
Ry4an Brase Avatar answered Nov 14 '22 08:11

Ry4an Brase


If you want to grab the contents of certain changesets and apply them to an arbitrary checkout (note: the resulting changesets will be different changesets, even if they make the same changes), take a look at the transplant extension.

like image 29
Amber Avatar answered Nov 14 '22 07:11

Amber