From: Julia Evans <julia@xxxxxxx>
Previously there were two explanations, this combines them both into a
single explanation.
Signed-off-by: Julia Evans <julia@xxxxxxx>
---
Documentation/git-rebase.adoc | 50 +++++++++++++++--------------------
1 file changed, 21 insertions(+), 29 deletions(-)
diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc
index 449f01fba560..e30b9535fff1 100644
--- a/Documentation/git-rebase.adoc
+++ b/Documentation/git-rebase.adoc
@@ -39,6 +39,27 @@ shortcut for `git checkout topic && git rebase master`.
D---E---F---G master
------------
+If there is a merge conflict during this process, `git rebase` will stop at the
+first problematic commit and leave conflict markers. If this happens, you can do
+one of these things:
+
+1. Resolve the conflict. You can use `git diff` to find 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. You can mark the conflict as
+ resolved with `git add <filename>`. After resolving all of the conflicts,
+ you can continue the rebasing process with
+
+ git rebase --continue
+
+2. Stop the `git rebase` and return your branch to its original state with
+
+ git rebase --abort
+
+3. Skip the commit that caused the merge conflict with
+
+ git rebase --skip
+
+
If `<branch>` is specified, `git rebase` will perform an automatic
`git switch <branch>` before doing anything else. Otherwise
it remains on the current branch.
@@ -74,13 +95,6 @@ any commits in `HEAD` which introduce the same textual changes as a commit
in `HEAD..<upstream>` are omitted (i.e., a patch already accepted upstream
with a different commit message or timestamp will be skipped).
-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`. Another option is to bypass the commit
-that caused the merge failure with `git rebase --skip`. To check out the
-original `<branch>` and remove the `.git/rebase-apply` working files, use
-the command `git rebase --abort` instead.
-
If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
will be skipped and warnings will be issued (if the 'merge' backend is
@@ -183,28 +197,6 @@ This is useful if F and G were flawed in some way, or should not be
part of topicA. Note that the argument to `--onto` and the `<upstream>`
parameter can be any valid commit-ish.
-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 add <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
-
MODE OPTIONS
------------
--
gitgitgadget
