Re: [PATCH v2] Documentation: pruning recipe for destructive filter-branch

> +git-filter-branch is often used to get rid of a subset of files,
> +usually with some combination of `\--index-filter` and
> +`\--subdirectory-filter`.  If you want to physically shrink the
> +repository afterwards, you have some choices:
> +
> +* Make sure you really removed all variants of a filename, if a blob
> +  was moved over its lifetime.  `git log \--name-only \--follow \--all
> +  \-- filename` can help you find renames.
> +
> +* Make sure you really filtered all refs: use `\--tag-name-filter cat
> +  \-- \--all` when calling git-filter-branch.
> +
> +* Clone it with `git clone file:///path/to/repo`.  The clone will not
> +  have the removed objects.  See linkgit:git-clone[1].  (Note that
> +  cloning with a plain path just hardlinks everything!)
> +
> +If you really don't want to clone it, for whatever reasons, check the
> +following points instead (in this order).  This is a very destructive
> +approach, so *make a backup* or go back to cloning it.  You have been
> +warned.
> +
> +* Remove the original refs backed up by git-filter-branch: say `git
> +  for-each-ref \--format="%(refname)" refs/original/ | xargs -n 1 git
> +  update-ref -d`.
> +
> +* Expire all reflogs with `git reflog expire \--expire=now \--all`.
> +
> +* Garbage collect all unreferenced objects with `git gc
> +  \--prune-expire=now` (or if your git-gc is not new enough to have
> +  that option, `git repack -ad; git prune`).