Differences between revisions 8 and 9

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

Scenarios

Now will be analyzed the most interesting scenarios.

Scenario A

The first one is the simplest one, a simple branch.

In this scenario there are two interesting interactions:

rebase on top

rebase on an intermediate revision

Scenario B

The second scenario involves something more complicated. In this scenario the user cloned from upstream, then merged several times.

rebase G on I

In this case the revision H has been skipped, because it would have been an empty revision.
rebase D on I

Despite being a merge revision D hasn't been skipped in this case.
rebase B on I

-  ⇤ ← Revision 8 as of 2008-07-13 21:13:25 → 
  Size: 2971
  Editor: StefanoTortarolo
  Comment:
+   ← Revision 9 as of 2008-07-15 17:25:13 → ⇥
  Size: 4878
  Editor: StefanoTortarolo
  Comment: Add section "Scenarios"
-Deletions are marked like this.
+Additions are marked like this.
 Line 127:
+== Scenarios ==
Now will be analyzed the most interesting scenarios.

=== Scenario A ===
The first one is the simplest one, a simple branch.

{{{#!dot
digraph {
    node [shape=box fontname=Courier];
    graph [rankdir=LR];

    A -> D -> E;
    A -> B -> C;
}
}}}

In this scenario there are two interesting interactions:

 * rebase on top

{{{#!dot
digraph {
    node [shape=box];
    graph [rankdir=LR];

    A -> D -> E;
    node [color=red];
    E -> B -> C;
    B [label="B`"];
    C [label="C`"];
}
}}}

 * rebase on an intermediate revision

{{{#!dot
digraph {
    node [shape=box];
    graph [rankdir=LR];

    A -> D -> E;
    node [color=red];
    D -> B -> C;
    B [label="B`"];
    C [label="C`"];
}
}}}

=== Scenario B ===
The second scenario involves something more complicated.
In this scenario the user cloned from upstream, then merged several times. 

{{{#!dot
digraph {
    node [shape=box];
    graph [rankdir=LR];

    A -> C -> E -> F -> I;
    A -> B -> D -> G -> H;
    C -> D;
    F -> H;
}
}}}

 * rebase G on I

{{{#!dot
digraph {
    node [shape=box];
    graph [rankdir=LR];

    A -> C -> E -> F -> I;
    A -> B -> D;
    C -> D;
    node [color=red];
    I -> G;
    G [label="G`"];
}
}}}
 In this case the revision H has been skipped, because it would have been an empty revision.

 * rebase D on I

{{{#!dot
digraph {
    node [shape=box];
    graph [rankdir=LR];

    A -> C -> E -> F -> I;
    A -> B;
    node [color=red];
    I -> D -> G;
    D [label="D`"];
    G [label="G`"];
}
}}}
 Despite being a merge revision D hasn't been skipped in this case.

 * rebase B on I

{{{#!dot
digraph {
    node [shape=box];
    graph [rankdir=LR];

    A -> C -> E -> F -> I;
    node [color=red];
    I -> B -> G;
    B [label="B`"];
    G [label="G`"];
}
}}}

Diff for "RebaseProject"