From: Junio C Hamano Date: Wed, 25 Dec 2019 19:22:00 +0000 (-0800) Subject: Merge branch 'ja/doc-markup-cleanup' X-Git-Tag: v2.25.0-rc0~7 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=dfee504bee4353fd7cede8b11e0090e20c69a032;p=thirdparty%2Fgit.git 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 --- dfee504bee4353fd7cede8b11e0090e20c69a032 diff --cc Documentation/git-filter-branch.txt index 3686a67d3e,ee889dd033..a530fef7e5 --- a/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: