Merge branch 'ja/doc-markup-cleanup'

Doc cleanup.

* ja/doc-markup-cleanup:
  doc: indent multi-line items in list
  doc: remove non pure ASCII characters

diff --cc Documentation/git-clone.txt
Simple merge

diff --cc Documentation/git-filter-branch.txt
index 3686a67d3e202e26e99ca16cc57ea17fd5492935,ee889dd033e80e63220c0e2fbd3fb060b3316176..a530fef7e5c08bf4bf01942ddbf1bcf10daa0b57
--- 1/Documentation/git-filter-branch.txt
--- 2/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@@ -623,44 -629,46 +629,46 @@@ with
       restored from refs/original/ in a previously botched rewrite).
  
  * Any commit messages that specify an encoding will become corrupted
- by the rewrite; git-filter-branch ignores the encoding, takes the original
- bytes, and feeds it to commit-tree without telling it the proper
- encoding.  (This happens whether or not --msg-filter is used.)
+   by the rewrite; git-filter-branch ignores the encoding, takes the
+   original bytes, and feeds it to commit-tree without telling it the
+   proper encoding.  (This happens whether or not --msg-filter is
+   used.)
  
  * Commit messages (even if they are all UTF-8) by default become
- corrupted due to not being updated -- any references to other commit
- hashes in commit messages will now refer to no-longer-extant commits.
- 
- * There are no facilities for helping users find what unwanted crud they
- should delete, which means they are much more likely to have incomplete
- or partial cleanups that sometimes result in confusion and people
- wasting time trying to understand.  (For example, folks tend to just
- look for big files to delete instead of big directories or extensions,
- and once they do so, then sometime later folks using the new repository
- who are going through history will notice a build artifact directory
- that has some files but not others, or a cache of dependencies
- (node_modules or similar) which couldn't have ever been functional since
- it's missing some files.)
+   corrupted due to not being updated -- any references to other commit
+   hashes in commit messages will now refer to no-longer-extant
+   commits.
+ 
+ * There are no facilities for helping users find what unwanted crud
+   they should delete, which means they are much more likely to have
+   incomplete or partial cleanups that sometimes result in confusion
+   and people wasting time trying to understand.  (For example, folks
+   tend to just look for big files to delete instead of big directories
+   or extensions, and once they do so, then sometime later folks using
+   the new repository who are going through history will notice a build
+   artifact directory that has some files but not others, or a cache of
+   dependencies (node_modules or similar) which couldn't have ever been
+   functional since it's missing some files.)
  
  * If --prune-empty isn't specified, then the filtering process can
- create hoards of confusing empty commits
+   create hoards of confusing empty commits
  
  * If --prune-empty is specified, then intentionally placed empty
- commits from before the filtering operation are also pruned instead of
- just pruning commits that became empty due to filtering rules.
+   commits from before the filtering operation are also pruned instead
+   of just pruning commits that became empty due to filtering rules.
  
 -* If --prune empty is specified, sometimes empty commits are missed
 +* If --prune-empty is specified, sometimes empty commits are missed
- and left around anyway (a somewhat rare bug, but it happens...)
+   and left around anyway (a somewhat rare bug, but it happens...)
  
  * A minor issue, but users who have a goal to update all names and
- emails in a repository may be led to --env-filter which will only update
- authors and committers, missing taggers.
+   emails in a repository may be led to --env-filter which will only
+   update authors and committers, missing taggers.
  
  * If the user provides a --tag-name-filter that maps multiple tags to
- the same name, no warning or error is provided; git-filter-branch simply
- overwrites each tag in some undocumented pre-defined order resulting in
- only one tag at the end.  (A git-filter-branch regression test requires
- this surprising behavior.)
+   the same name, no warning or error is provided; git-filter-branch
+   simply overwrites each tag in some undocumented pre-defined order
+   resulting in only one tag at the end.  (A git-filter-branch
+   regression test requires this surprising behavior.)
  
  Also, the poor performance of git-filter-branch often leads to safety
  issues: