This case represents a quite common situation, a repository with just one (merge) head. Note: Prior Mercurial 2.3 you need to had -detach option in this situation. In this case two revisions (D and H) have been skipped.In this scenario the user cloned from upstream, then merged several times.ĭespite being a merge revision D hasn't been skipped in this case, as opposite to H. The second scenario involves something more complicated. In this scenario there are two interesting interactions:Īnother syntax that would yield the same result is:ħ.1.2. The first one is the simplest one, a simple branch. Now will be analyzed the most interesting scenarios. This adds an export-like header to each rebased patch. In the current implementation MQ patches are qfinished and qimported after being rebased. the rebasing point (source) is a merge revision and both of its parents are external.the rebasing point (source) is an ancestor of target.There are situations in which a rebasing process is not allowed: The most common situation, however, is resuming an interrupted process and this can be done with: In event of an interruption, users have two choices:Īn interrupted process can be aborted, thus restoring the repository to its original state, with: In these cases, the extension will stop, store the current status, and provide the user with the ability to solve the conflict on his own. See histedit for a tool that helps automate some of the more common tasks.Ī situation could arise where some changes we're rebasing conflict with some changes in the destination.
#Rebase tortoisehg series#
Just about any rearrangement of history is possible with a series of rebases. Lastly, let's imagine Y3 and Z3 really ought to be one commit. We could fix this by moving Y2 to descend from E and then strip X2: Now let's imagine we decided commit X2 was a mistake. Thus we've given our changesets updated names. Note: moving changesets changes their changeset hashes and revision numbers.
This command will take commit from the source X and all its descendants and "move" them to descend instead from the destination E: We can easily "linearize" the history by running: Here we have local commits X through Z diverging from the upstream line of history A through E. Let's imagine our repository looks like this: collapsing multiple changes into one changesetĮnable the extension in the configuration file (e.g.hg/hgrc):.Rebase allows moving commits around in Mercurial's history (using a series of internal merges).
0 kommentar(er)
