dir.c: use a single struct exclude_list per source of excludes

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index a9e0e503cb264ac02b123395ae9c8d0b4a98ebde..feb51a6ea3e9cd3ddca3179b4cf542cf39f0efc1 100644 (file)
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -45,7 +45,7 @@ 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 restore the
+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.
 
@@ -232,7 +232,15 @@ leave out at most one of A and B, in which case it defaults to HEAD.
        Restart the rebasing process after having resolved a merge conflict.
 
 --abort::
-       Restore the original branch and abort the rebase operation.
+       Abort the rebase operation and reset HEAD to the original
+       branch. If <branch> was provided when the rebase operation was
+       started, then HEAD will be reset to <branch>. Otherwise HEAD
+       will be reset to where it was when the rebase operation was
+       started.
+
+--keep-empty::
+       Keep the commits that do not change anything from its
+       parents in the result.
 
 --skip::
        Restart the rebasing process by skipping the current patch.
@@ -263,9 +271,9 @@ which makes little sense.
 -X <strategy-option>::
 --strategy-option=<strategy-option>::
        Pass the <strategy-option> through to the merge strategy.
-       This implies `\--merge` and, if no strategy has been
+       This implies `--merge` and, if no strategy has been
        specified, `-s recursive`.  Note the reversal of 'ours' and
-       'theirs' as noted in above for the `-m` option.
+       'theirs' as noted above for the `-m` option.
 
 -q::
 --quiet::
@@ -405,10 +413,13 @@ The interactive mode is meant for this type of workflow:
 
 where point 2. consists of several instances of
 
-a. regular use
+a) regular use
+
  1. finish something worthy of a commit
  2. commit
-b. independent fixup
+
+b) independent fixup
+
  1. realize that something does not work
  2. fix that
  3. commit it
@@ -604,8 +615,8 @@ Easy case: The changes are literally the same.::
 Hard case: The changes are not the same.::
 
        This happens if the 'subsystem' rebase had conflicts, or used
-       `\--interactive` to omit, edit, squash, or fixup commits; or
-       if the upstream used one of `commit \--amend`, `reset`, or
+       `--interactive` to omit, edit, squash, or fixup commits; or
+       if the upstream used one of `commit --amend`, `reset`, or
        `filter-branch`.
 
 
@@ -641,7 +652,7 @@ correspond to the ones before the rebase.
 NOTE: While an "easy case recovery" sometimes appears to be successful
       even in the hard case, it may have unintended consequences.  For
       example, a commit that was removed via `git rebase
-      \--interactive` will be **resurrected**!
+      --interactive` will be **resurrected**!
 
 The idea is to manually tell 'git rebase' "where the old 'subsystem'
 ended and your 'topic' began", that is, what the old merge-base
@@ -649,7 +660,7 @@ between them was.  You will have to find a way to name the last commit
 of the old 'subsystem', for example:
 
 * With the 'subsystem' reflog: after 'git fetch', the old tip of
-  'subsystem' is at `subsystem@\{1}`.  Subsequent fetches will
+  'subsystem' is at `subsystem@{1}`.  Subsequent fetches will
   increase the number.  (See linkgit:git-reflog[1].)
 
 * Relative to the tip of 'topic': knowing that your 'topic' has three