Size: 1957
Comment:
|
Size: 2956
Comment: Add "Rebasing merged revisions" section
|
Deletions are marked like this. | Additions are marked like this. |
Line 19: | Line 19: |
* mq patches handling | |
Line 46: | Line 47: |
rankdir=LR node [shape=box] C1 -> C2 -> R1 -> R2 -> l1 -> l2 |
rankdir=LR; node [shape=box]; C1 -> C2 -> R1 -> R2 -> R3; node [color=red]; R3 -> L1 -> L2; L1 [label="L1`"]; L2 [label="L2`"]; } }}} == Rebasing merged revisions == This is a common situation, in which we have cloned a repository and then merged with it. {{{#!dot digraph { rankdir=LR; center=true; node [shape=box]; C1 -> C2 -> R1 -> R2; C1 -> L1 -> L2; C2 -> L2; } }}} In this case the expected result of rebasing L2 on top of R2 is: {{{#!dot digraph { rankdir=LR; center=true; node [shape=box]; C1 -> C2 -> R1 -> R2; C1 -> L1; node [color=red]; R2 -> L2; L2 [label="L2`"]; } }}} But if we tried to rebase starting from L1, then ''rebase'' would recognize that L2 is an empty revision and it would skip it. {{{#!dot digraph G { rankdir=LR; center=true; node [shape=box]; C1 -> C2 -> R1 -> R2; node [color=red]; R2 -> L1; L1 [label="L1`"]; |
Line 74: | Line 126: |
---- CategoryNewFeatures |
Rebase Project
Introduction
When contributing to a project, sometimes there is the need to keep some patches private, while keeping the whole repository up-to-date.
In those cases it can be useful to "detach" the local changes, synchronize the repository with the mainstream and then append the private changes on top of the new remote changes. This operation is called rebase.
This feature is being implemented as part of SummerOfCode.
Current implementation
The current code can be find [http://freehg.org/u/astratto/soc/ here]
Current version's features:
- rebase both simple and complex cases
- abort of an interrupted rebasing
- resume of an interrupted rebasing
- mq patches handling
Usage examples
Let suppose we have the following repository
where C* are common revisions, R* changes in upstream and L* local changes.
Simple case
We want to rebase L* on top of R2.
This can be achieved using:
$ hg rebase L1 R2
Result:
Rebasing merged revisions
This is a common situation, in which we have cloned a repository and then merged with it.
In this case the expected result of rebasing L2 on top of R2 is:
But if we tried to rebase starting from L1, then rebase would recognize that L2 is an empty revision and it would skip it.
Dealing with conflicting merges
Sometimes could happen that some changes in L* conflicts with some changes in R*. In these cases the extension will stop, store the current status and let user the ability to solve the conflict on his own.
In event of interruption users have two choices:
- abort
- continue
Abort
An interrupted process can be aborted, thus restoring the repository to its original state, with:
hg rebase --abort
Continue
The most common situation, however, is resuming an interrupted process and this can be done with:
hg rebase --continue
Related links
[http://code.google.com/soc/2008/hg/appinfo.html?csaid=EC7D811E53CA98EF GSoC's Abstract ]