From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 4 Dec 2018 03:49:39 +0000 (+0900)
Subject: Merge branch 'en/rebase-consistency'
X-Git-Tag: v2.20.0~3
X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/5335669531d83d7d6c905bcfca9b5f8e182dc4d4?ds=inline;hp=-c

Merge branch 'en/rebase-consistency'

* en/rebase-consistency:
rebase docs: fix incorrect format of the section Behavioral Differences
---

5335669531d83d7d6c905bcfca9b5f8e182dc4d4
diff --combined Documentation/git-rebase.txt
index 80793bad8d,41631df6e4..dff17b3178
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@@ -203,7 -203,7 +203,7 @@@ Alternatively, you can undo the 'git re
  CONFIGURATION
  -------------
  
 -include::rebase-config.txt[]
 +include::config/rebase.txt[]
  
  OPTIONS
  -------
@@@ -441,8 -441,7 +441,8 @@@ See also INCOMPATIBLE OPTIONS below
  --exec <cmd>::
  	Append "exec <cmd>" after each line creating a commit in the
  	final history. <cmd> will be interpreted as one or more shell
 -	commands.
 +	commands. Any command that fails will interrupt the rebase,
 +	with exit code 1.
  +
  You may execute several commands by either using one instance of `--exec`
  with several commands:
@@@ -550,24 -549,28 +550,28 @@@ Other incompatible flag pairs
  BEHAVIORAL DIFFERENCES
  -----------------------
  
-  * empty commits:
+ There are some subtle differences how the backends behave.
  
-     am-based rebase will drop any "empty" commits, whether the
-     commit started empty (had no changes relative to its parent to
-     start with) or ended empty (all changes were already applied
-     upstream in other commits).
+ Empty commits
+ ~~~~~~~~~~~~~
  
-     merge-based rebase does the same.
+ The am backend drops any "empty" commits, regardless of whether the
+ commit started empty (had no changes relative to its parent to
+ start with) or ended empty (all changes were already applied
+ upstream in other commits).
  
-     interactive-based rebase will by default drop commits that
-     started empty and halt if it hits a commit that ended up empty.
-     The `--keep-empty` option exists for interactive rebases to allow
-     it to keep commits that started empty.
+ The merge backend does the same.
  
-   * directory rename detection:
+ The interactive backend drops commits by default that
+ started empty and halts if it hits a commit that ended up empty.
+ The `--keep-empty` option exists for the interactive backend to allow
+ it to keep commits that started empty.
  
-     merge-based and interactive-based rebases work fine with
-     directory rename detection.  am-based rebases sometimes do not.
+ Directory rename detection
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 
+ The merge and interactive backends work fine with
+ directory rename detection.  The am backend sometimes does not.
  
  include::merge-strategies.txt[]
  
@@@ -642,9 -645,6 +646,9 @@@ By replacing the command "pick" with th
  the files and/or the commit message, amend the commit, and continue
  rebasing.
  
 +To interrupt the rebase (just like an "edit" command would do, but without
 +cherry-picking any commit first), use the "break" command.
 +
  If you just want to edit the commit message for a commit, replace the
  command "pick" with the command "reword".
  
@@@ -889,7 -889,7 +893,7 @@@ The ripple effect of a "hard case" reco
  case" recovery too!
  
  REBASING MERGES
 ------------------
 +---------------
  
  The interactive rebase command was originally designed to handle
  individual patch series. As such, it makes sense to exclude merge
@@@ -958,14 -958,14 +962,14 @@@ command fails, it is rescheduled immedi
  to proceed.
  
  The `reset` command resets the HEAD, index and worktree to the specified
 -revision. It is isimilar to an `exec git reset --hard <label>`, but
 +revision. It is similar to an `exec git reset --hard <label>`, but
  refuses to overwrite untracked files. If the `reset` command fails, it is
  rescheduled immediately, with a helpful message how to edit the todo list
  (this typically happens when a `reset` command was inserted into the todo
  list manually and contains a typo).
  
 -The `merge` command will merge the specified revision into whatever is
 -HEAD at that time. With `-C <original-commit>`, the commit message of
 +The `merge` command will merge the specified revision(s) into whatever
 +is HEAD at that time. With `-C <original-commit>`, the commit message of
  the specified merge commit will be used. When the `-C` is changed to
  a lower-case `-c`, the message will be opened in an editor after a
  successful merge so that the user can edit the message.
@@@ -974,8 -974,7 +978,8 @@@ If a `merge` command fails for any reas
  when the merge operation did not even start), it is rescheduled immediately.
  
  At this time, the `merge` command will *always* use the `recursive`
 -merge strategy, with no way to choose a different one. To work around
 +merge strategy for regular merges, and `octopus` for octopus merges,
 +strategy, with no way to choose a different one. To work around
  this, an `exec` command can be used to call `git merge` explicitly,
  using the fact that the labels are worktree-local refs (the ref
  `refs/rewritten/onto` would correspond to the label `onto`, for example).