+git-rebase replaces <branch> with a new branch of the same name. When
+the --onto option is provided the new branch starts out with a HEAD equal
+to <newbase>, otherwise it is equal to <upstream>. It then attempts to
+create a new commit for each commit from the original <branch> that does
+not exist in the <upstream> branch.
+
+It is possible that a merge failure will prevent this process from being
+completely automatic. You will have to resolve any such merge failure
+and run `git rebase --continue`. If you can not resolve the merge
+failure, running `git rebase --abort` will restore the original <branch>
+and remove the working files found in the .dotest directory.
+
+Note that if <branch> is not specified on the command line, the currently
+checked out branch is used.
+
+Assume the following history exists and the current branch is "topic":
+
+------------
+ A---B---C topic
+ /
+ D---E---F---G master
+------------
+
+From this point, the result of either of the following commands:
+
+
+ git-rebase master
+ git-rebase master topic
+
+would be:
+
+------------
+ A'--B'--C' topic
+ /
+ D---E---F---G master
+------------
+
+While, starting from the same point, the result of either of the following
+commands:
+
+ git-rebase --onto master~1 master
+ git-rebase --onto master~1 master topic
+
+would be:
+
+------------
+ A'--B'--C' topic
+ /
+ D---E---F---G master
+------------
+
+In case of conflict, git-rebase will stop at the first problematic commit
+and leave conflict markers in the tree. You can use git diff to locate
+the markers (<<<<<<) and make edits to resolve the conflict. For each
+file you edit, you need to tell git that the conflict has been resolved,
+typically this would be done with
+
+
+ git update-index <filename>
+
+
+After resolving the conflict manually and updating the index with the
+desired resolution, you can continue the rebasing process with
+
+
+ git rebase --continue
+
+
+Alternatively, you can undo the git-rebase with
+
+
+ git rebase --abort