I know Rebase is a (bundled) extension, while Graft is a core feature (that replaced the Transplant (bundled) extension).
graft is documented as:
copy changes from other branches onto the current branch
This command uses Mercurial's merge logic to copy individual changes from other branches without merging branches in the history graph. This is sometimes known as 'backporting' or 'cherry-picking'.
rebase is documented as:
Rebase allows moving commits around in Mercurial's history (using a series of internal merges). This has many uses:
moving changesets between branches
"linearizing" history
reordering changesets
collapsing multiple changes into one changeset
Both seem to use merging to move or copy changesets between branches.
Graft copies. Rebase moves. But rebase --keep copies.
So often it seems I can accomplish my goal of copying a changeset either way.
Does it matter which one I use? When should I prefer one over the other?
E.g. should graft only be used when copying to a different named branch? Or only when there's just a single changeset?
Edit: Could it be that rebase is a potentially unsafe superset of graft, but can only be used with draft changesets during development for editing local history, while graft is a safe subset of rebase that can be used with public changesets during maintenance for backporting?
hg graft allows "cherry-picking," as you noted in your question. For example, you can run hg graft -D "2085::2093 and not 2091" to copy only some changes from another revision. By comparison, hg rebase (with or without --keep) will grab whatever changeset you specify and all of its decendant changes.
Also, rebase allows you to collapse changesets (with --collapse). As far as I can tell, graft does not.
One more difference I have noticed: hg graft --edit 123 lets you graft revision 123 to the working directory and edit the commit message. I can't find an hg rebase equivalent. I should point out, though, that hg histedit also allows for editing the commit message while rebasing.
There are probably other differences that I am not thinking of. SO community: feel free to point those out in the comments, and I will happily revise this answer to make it more complete.
See the graft documentation and the Rebase Extension documentation for more details.
Related
I am currently using Mercurial for sub-version control in my project. Now I am suppose to work on a new branch 2.7 but I confuse to work with branch 2.6, I have developed the new feature which the feature on 2.7 but I build on 2.6. And now I want to move this feature to branch 2.7 properly but I don't know how can I move it properly. Is there any way?
I would recommend using hg graft, which copies changes from one branch to another and unlike hg rebase is not destructive (relevant if you're doing this for the first time and may be making mistakes or if you need the feature to be present on both branches).
To copy changes to a branch dest-branch, do the following. First update to the branch you want to copy the changes to:
hg update dest-branch
Then, use graft to copy the revisions you want from the original branch, e.g.:
hg graft -r start..end
where start is the first revision you want to graft from the source branch and end is the last revision.
You may encounter conflicts if they can't be merged cleanly, which you have to resolve them (as you'd do in a merge), then use hg graft --continue to graft the remaining revisions.
The magic word is RTFM - hg help rebase
I'm trying to rebase some changes I pulled in to my local machine. I'm getting the error:
abort: can't rebase immutable changeset 110e73ed65a4
(see hg help phases for details)
And I get the same error even after I change the phase on the changesets that I'm rebaseing (and the phase change seems to be successful). using:
hg phase -f -d REV
I'm wondering if there's a changeset in the history that I'm missing and is still immutable, and if so, if there is a way that I can change all of the changesets in a changeset's history to be mutable with a single command.
Or, is there a way to force rebase, even with the immutable changesets?
Rebasing changes that are public is considered a very bad idea. You shouldn't change any history that's been pushed -- the point of phases is to track what changes haven't been pushed yet (so they're able to be modified), and what changes have been pushed (so they're immutable). From the rebase documentation:
You should not rebase changesets that have already been shared with others. Doing so will force everybody else to perform the same rebase or they will end up with duplicated changesets after pulling in your rebased changesets.
It's better to either merge in your changes or graft them in. Graft (also known as cherry-picking) takes one or more changesets and copies them to your current branch.
I am new to Mercurial and still somehow in the evaluation process, so these four concepts are kind of confusing for me. Some are mentioned to be an equivalent to Git's Staging/Index concept, or some even a better one than Git's Staging.
How do the four commands hg graft, hg record, hg qrecord and hg shelve (and hg transplant, but this is explained in Graft vs. Transplant already) compare to each other, and how the concepts of queues and the dirstate? In which use cases is one choosen over the other?
I know there are help pages for each one, but it still is difficult to figure out what each one does as VCS in general is a new topic for me.
The design of Mercurial simply does not include the concept of a staging area. That is, there is no intermediate state between local modification and commit.
Here is an overview of each of the concepts you mentioned:
hg graft is the equivalent of git cherry-pick. It copies a commit from one branch to another. A typical use case for this feature is to copy a bug fix from one release branch to another. This command replaces the older (and now obsolete) hg transplant extension.
hg record and hg qrecord are similar to git add --patch. They allow you to interactively select hunks for commit. So if you modified several different areas of one file, you could select which areas (i.e. hunks) you actually want to commit and which you want to leave as local modifications.
qrecord is only available if you have mq enabled. It commits to an mq patch rather than a standard commit.
hg shelve is similar to git stash. It allows you to temporarily set aside local modifications to your files (or hunks of a file). These modifications can then be unshelved when you are ready for them.
dirstate is an internal class of of the Mercurial source code. It is not exposed to the user.
Mercurial Queues (also know as mq) are probably the closest you will get to a staging area in Mercurial. Here is a description from the Mercurial wiki:
Changes are maintained as patches which are committed into Mercurial.
Commits can be removed or reordered, and the underlying patch can be
refreshed based on changes made in the working directory. The patch
directory can also be placed under revision control, so you can have a
separate history of changes made to your patches.
mq is often used to polish/rework commits that you are testing locally, but have not pushed to a public location. Some people also use it to maintain a set of modifications to 3rd party code.
In my repo, I have the revisions 1 to 10. I've pushed up to 5 (so the next hg push would publish revisions 6-10).
But I have to interrupt my work now and the result isn't 100% complete. So I'd like to move the revisions 6-10 into a new "experimental" branch to allow someone else to complete the work without disrupting the sources for everyone.
How can I add a branch to a non-tip revision (in my case: Starting with revision 6)? Or should I use a completely different approach?
You cannot apply a branch name after the fact without modifying your history.
The most simple approach is to ask the other users to use revision 5 as the parent for any changes they create. For example, the other users would:
hg clone <your repo> or even hg clone --rev 5
hg update -r 5
work, work, work
hg commit
When they commit a change, it will create a second head on the default branch, but that should not create any problems. You will simply need to merge the two heads together once your experimental changes are complete.
That being said, moving your changesets onto a branch can be accomplished using Mercurial Queues (MQ). The following sequence shows how it be done:
hg qinit (Create a new patch queue)
hg qimport --rev 6:10 (import r6-10 into a new patch queue)
hg qpop -a (remove all patches from your working copy)
hg branch <branch name> (create your new experimental branch)
hg qpush -a (apply all the patches to your branch)
hg qfinish -a (convert all patches to permanent changesets)
Tim already has good suggestions. Additionally you could push your experimental changes into a distinct experimental clone on your central server (I guess you use one). This clone could also be used by other developers to push their not-yet-finished work in order to let others review or continue it. It is also clear that this clone's code is not ready to be used. Once some task is finished, the corresponding changesets can be pushed to the stable repository.
Actually named branches are a good idea for your case, but the fact that their names are burned into history mostly is more a problem than a feature. IMHO Git's branch names are more practically. However, to some extend you could also handle your case with bookmarks, which are pushable since Mercurial 1.7 (not sure here). That is you bookmark revision 5 with something like stable (or whatever you agree on in your team) and revision 10 gets bookmarked with something like Aarons-not-finished-work. The other developers would then just pull stable, except your colleague who is supposed to continue your work, who would pull the other bookmark. However, personally I did not use a such workflow yet, so I cannot say if it performs well in practice.
I had 3 change sets that I wanted to rebase on top of the latest revisions. Unfortunately, I selected only one of them to be rebased and so this did a merge. Is there any way I can either undo the rebase or change it so the other two change sets get rebased as well?
Assuming you haven't pushed it to another repo for others to grab, then you can put those changesets anywhere on the graph you want. You can move changesets with hg rebase and prune changsets and their descendents with hg strip.
Both strip and rebase save "undo" information as bundle files in your .hg/strip-backup/
Note that neither strip nor rebase are enabled by default with mercurial. You need to enable them in the .hgrc file.
If it's the very last thing you did you can do a 'hg rollback' which is a one-level undo. If, however, you've done anything since that alters the repository state (push, pull, commit, etc.) then rollback won't help you.
If it's any consolation, merging is generally preferable to rebasing and a mercurial history with a lot of merges shows someone who is using mercurial to its fullest. :)