filter-branch

NAME名

git-filter-branch - Rewrite branchesgit-filter-branch - ブランチを書き換える

SYNOPSIS概要

git filter-branch [--setup <command>] [--subdirectory-filter <directory>]
	[--env-filter <command>] [--tree-filter <command>]
	[--index-filter <command>] [--parent-filter <command>]
	[--msg-filter <command>] [--commit-filter <command>]
	[--tag-name-filter <command>] [--prune-empty]
	[--original <namespace>] [-d <directory>] [-f | --force]
	[--state-branch <branch>] [--] [<rev-list options>…]

DESCRIPTION説明

Lets you rewrite Git revision history by rewriting the branches mentioned in the <rev-list options>, applying custom filters on each revision. Those filters can modify each tree (e.g. removing a file or running a perl rewrite on all files) or information about each commit. Otherwise, all information (including original commit times or merge information) will be preserved.<rev-list options>に記載されているブランチを書き換えて、各リビジョンにカスタムフィルタを適用することで、Gitのリビジョン履歴を書き換えることができます。これらのフィルタは各ツリーを修正することができます（例えば、ファイルを削除したり、すべてのファイルに対してperlの書き換えを実行したり）、あるいは各コミットに関する情報。それ以外の場合は、すべての情報（元のコミット時間またはマージ情報を含む）が保持されます。

The command will only rewrite the positive refs mentioned in the command line (e.g. if you pass a..b, only b will be rewritten). If you specify no filters, the commits will be recommitted without any changes, which would normally have no effect. Nevertheless, this may be useful in the future for compensating for some Git bugs or such, therefore such a usage is permitted.コマンドは、コマンドラインで言及された正の参照だけを書き換えます（例えば、a..bを渡すと、bだけが書き換えられます）。フィルタを指定しないと、コミットは変更されずに再コミットされます。通常、これは効果がありません。それにもかかわらず、これは将来的にはいくつかのGitバグなどを補正するのに役立つかもしれません、それでそのような使用法は許されます。

NOTE: This command honors .git/info/grafts file and refs in the refs/replace/ namespace. If you have any grafts or replacement refs defined, running this command will make them permanent.注：このコマンドは.git/info/graftsファイルを優先し、refs/replace/名前空間を参照します。移植片または置換用の参照が定義されている場合は、このコマンドを実行するとそれらが永続的になります。

WARNING! The rewritten history will have different object names for all the objects and will not converge with the original branch. You will not be able to easily push and distribute the rewritten branch on top of the original branch. Please do not use this command if you do not know the full implications, and avoid using it anyway, if a simple single commit would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM REBASE" section in git-rebase[1] for further information about rewriting published history.)警告！書き換えられた履歴は、すべてのオブジェクトに対して異なるオブジェクト名を持ち、元のブランチと収束しません。書き換えたブランチを元のブランチの上に簡単にプッシュして配布することはできません。完全な意味がわからない場合はこのコマンドを使用しないでください。問題を解決するために単純な単一のコミットで十分な場合は、使用しないでください。（公開された履歴の書き換えについての詳細は、git-rebase [1]の「UPSTREAM REBASEからの回復」を参照してください。）

Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace refs/original/.書き換えられたバージョンが正しいことを常に確認してください。元の参照は、書き換えられたものと異なる場合は、名前空間refs / original /に格納されます。

Note that since this operation is very I/O expensive, it might be a good idea to redirect the temporary directory off-disk with the -d option, e.g. on tmpfs. Reportedly the speedup is very noticeable.この操作はI / Oの負荷が非常に高いので、-dオプションを使って一時ディレクトリをオフディスクにリダイレクトすることをお勧めします（例：tmpfs）。伝えられるところによれば、スピードアップは非常に顕著です。

Filtersフィルター

The filters are applied in the order as listed below. The <command> argument is always evaluated in the shell context using the eval command (with the notable exception of the commit filter, for technical reasons). Prior to that, the $GIT_COMMIT environment variable will be set to contain the id of the commit being rewritten. Also, GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and GIT_COMMITTER_DATE are taken from the current commit and exported to the environment, in order to affect the author and committer identities of the replacement commit created by git-commit-tree[1] after the filters have run.フィルタは以下の順番で適用されます。<command>引数は、evalコマンドを使用してシェルコンテキストで常に評価されます（技術的な理由から、commitフィルタを除いて）。それ以前$GIT_COMMITは、書き換えられるコミットのIDを含むように環境変数が設定されます。また、GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_AUTHOR_DATE、GIT_COMMITTER_NAME、GIT_COMMITTER_EMAIL、およびGIT_COMMITTER_DATEは、交換の作者とコミッタのアイデンティティに影響を与えるためにによって作成されたコミット、コミット、現在の環境にエクスポートから取られている[1] gitのコミットツリーの後にフィルタが実行されました。

If any evaluation of <command> returns a non-zero exit status, the whole operation will be aborted.<command>の評価でゼロ以外の終了ステータスが返された場合、操作全体が中止されます。

A map function is available that takes an "original sha1 id" argument and outputs a "rewritten sha1 id" if the commit has been already rewritten, and "original sha1 id" otherwise; the map function can return several ids on separate lines if your commit filter emitted multiple commits.マップ機能は、そうでなければ、「オリジナルSHA1 ID」を既に書き換えられているコミット、および場合は、「オリジナルSHA1 IDが」引数をとり、「書き換えSHA1 ID」を出力する使用可能です。コミットフィルタが複数のコミットを発行した場合、map関数は別々の行に複数のIDを返すことができます。

OPTIONSオプション

--setup <command> --setup <コマンド>

This is not a real filter executed for each commit but a one time setup just before the loop. Therefore no commit-specific variables are defined yet. Functions or variables defined here can be used or modified in the following filter steps except the commit filter, for technical reasons.これはコミットごとに実行される実際のフィルタではなく、ループの直前に一度だけ設定されるものです。したがって、コミット固有の変数はまだ定義されていません。ここで定義されている関数または変数は、技術的な理由から、コミットフィルター以外の次のフィルターステップで使用または変更できます。

--subdirectory-filter <directory> --subdirectory-filter <ディレクトリ>

Only look at the history which touches the given subdirectory. The result will contain that directory (and only that) as its project root. Implies Remap to ancestor.与えられたサブディレクトリに触れる歴史だけを見てください。結果には、そのディレクトリ（およびそれだけ）がプロジェクトのルートとして含まれます。意味先祖に再マップを。

--env-filter <command> --env-filter <コマンド>

This filter may be used if you only need to modify the environment in which the commit will be performed. Specifically, you might want to rewrite the author/committer name/email/time environment variables (see git-commit-tree[1] for details).このフィルタは、コミットが実行される環境を変更するだけでよい場合に使用できます。具体的には、作成者/コミッター名/ email / time環境変数を書き換えることをお勧めします（詳細はgit-commit-tree [1]を参照）。

--tree-filter <command> --tree-filter <コマンド>

This is the filter for rewriting the tree and its contents. The argument is evaluated in shell with the working directory set to the root of the checked out tree. The new tree is then used as-is (new files are auto-added, disappeared files are auto-removed - neither .gitignore files nor any other ignore rules HAVE ANY EFFECT!).これはツリーとその内容を書き換えるためのフィルタです。引数は、チェックアウトされたツリーのルートに設定された作業ディレクトリを使用してシェル内で評価されます。新しいツリーはそのまま使用されます（新しいファイルは自動的に追加され、消えたファイルは自動的に削除されます - .gitignoreファイルも他の無視ルールも効果がありません）。

--index-filter <command> --index-filter <コマンド>

This is the filter for rewriting the index. It is similar to the tree filter but does not check out the tree, which makes it much faster. Frequently used with git rm --cached --ignore-unmatch ..., see EXAMPLES below. For hairy cases, see git-update-index[1].これはインデックスを書き換えるためのフィルタです。これはツリーフィルタに似ていますが、ツリーをチェックアウトしないため、はるかに高速になります。よく使用されgit rm --cached --ignore-unmatch ...ます。以下の例を参照してください。毛深い場合はgit-update-index [1]を参照してください。

--parent-filter <command> --parent-filter <コマンド>

This is the filter for rewriting the commit’s parent list. It will receive the parent string on stdin and shall output the new parent string on stdout. The parent string is in the format described in git-commit-tree[1]: empty for the initial commit, "-p parent" for a normal commit and "-p parent1 -p parent2 -p parent3 …" for a merge commit.これはコミットの親リストを書き換えるためのフィルタです。それは標準入力に親文字列を受け取り、標準出力に新しい親文字列を出力します。親の文字列は、git-commit-tree [1]で説明されているフォーマットです。初期コミットの場合は空、通常のコミットの場合は "-p parent"、マージの場合は "-p parent1 -p parent2 -p parent3…"です。コミット。

--msg-filter <command> --msg-filter <コマンド>

This is the filter for rewriting the commit messages. The argument is evaluated in the shell with the original commit message on standard input; its standard output is used as the new commit message.これはコミットメッセージを書き換えるためのフィルタです。引数は、標準入力の元のコミットメッセージを使用してシェル内で評価されます。その標準出力は新しいコミットメッセージとして使用されます。

--commit-filter <command> --commit-filter <コマンド>

This is the filter for performing the commit. If this filter is specified, it will be called instead of the git commit-tree command, with arguments of the form "<TREE_ID> [(-p <PARENT_COMMIT_ID>)…]" and the log message on stdin. The commit id is expected on stdout.これはコミットを実行するためのフィルタです。このフィルタを指定すると、git commit-treeコマンドの代わりに、"<TREE_ID> [（-p <PARENT_COMMIT_ID>…]" "の形式の引数と標準入力のログメッセージを指定して呼び出されます。コミットIDは標準出力に期待されています。

As a special extension, the commit filter may emit multiple commit ids; in that case, the rewritten children of the original commit will have all of them as parents.特別な拡張として、コミットフィルタは複数のコミットIDを発行することがあります。その場合、元のコミットの書き換えられた子供たちは、親として彼ら全員を持つことになります。

You can use the map convenience function in this filter, and other convenience functions, too. For example, calling skip_commit "$@" will leave out the current commit (but not its changes! If you want that, use git rebase instead).このフィルタではマップ便利機能や他の便利機能も使用できます。たとえば、skip_commit "$ @"を呼び出すと、現在のコミットは削除されます（ただし、変更は行われません！必要に応じて、代わりにgit rebaseを使用してください）。

You can also use the git_commit_non_empty_tree "$@" instead of git commit-tree "$@" if you don’t wish to keep commits with a single parent and that makes no change to the tree.コミットを単一の親と一緒にしたくない場合は、git_commit_non_empty_tree "$@"代わりにを使用することもできgit commit-tree "$@"ます。これはツリーに変更を加えません。

--tag-name-filter <command> --tag-name-filter <コマンド>

This is the filter for rewriting tag names. When passed, it will be called for every tag ref that points to a rewritten object (or to a tag object which points to a rewritten object). The original tag name is passed via standard input, and the new tag name is expected on standard output.これはタグ名を書き換えるためのフィルタです。渡されると、書き換えられたオブジェクト（または書き換えられたオブジェクトを指すタグオブジェクト）を指すすべてのtag refに対して呼び出されます。元のタグ名は標準入力を介して渡され、新しいタグ名は標準出力に予期されます。

The original tags are not deleted, but can be overwritten; use "--tag-name-filter cat" to simply update the tags. In this case, be very careful and make sure you have the old tags backed up in case the conversion has run afoul.元のタグは削除されませんが、上書きすることができます。単にタグを更新するには "--tag-name-filter cat"を使用してください。この場合は、細心の注意を払って、変換に問題がある場合に備えて古いタグをバックアップしてください。

Nearly proper rewriting of tag objects is supported. If the tag has a message attached, a new tag object will be created with the same message, author, and timestamp. If the tag has a signature attached, the signature will be stripped. It is by definition impossible to preserve signatures. The reason this is "nearly" proper, is because ideally if the tag did not change (points to the same object, has the same name, etc.) it should retain any signature. That is not the case, signatures will always be removed, buyer beware. There is also no support for changing the author or timestamp (or the tag message for that matter). Tags which point to other tags will be rewritten to point to the underlying commit.タグオブジェクトのほぼ適切な書き換えがサポートされています。タグにメッセージが添付されている場合は、同じメッセージ、作成者、およびタイムスタンプを使用して新しいタグオブジェクトが作成されます。タグに署名が添付されている場合、その署名は削除されます。署名を保存することは定義上不可能です。これが「ほぼ」適切である理由は、理想的にはタグが変更されなかった場合（同じオブジェクトを指している、同じ名前を持っている場合など）、署名を保持する必要があるためです。そうではありません、署名は常に削除されます、買い手は用心します。作者やタイムスタンプ（あるいはそのことに関するタグメッセージ）を変更することもサポートされていません。他のタグを指すタグは、基礎となるコミットを指すように書き直されます。

--prune-empty

Some filters will generate empty commits that leave the tree untouched. This option instructs git-filter-branch to remove such commits if they have exactly one or zero non-pruned parents; merge commits will therefore remain intact. This option cannot be used together with --commit-filter, though the same effect can be achieved by using the provided git_commit_non_empty_tree function in a commit filter.いくつかのフィルタは、木をそのままにしておく空のコミットを生成します。このオプションはgit-filter-branchにそのようなコミットが削除されていない親を正確に1つか0つ持っている場合は削除するよう指示します。したがって、マージコミットはそのまま残ります。このオプションを同時に使用することはできませんが、コミットフィルタで--commit-filter提供されているgit_commit_non_empty_tree関数を使用して同じ効果を得ることができます。

--original <namespace> --original <名前空間>

Use this option to set the namespace where the original commits will be stored. The default value is refs/original.このオプションを使用して、元のコミットが保存される名前空間を設定します。デフォルト値はrefs / originalです。

-d <directory> -d <ディレクトリ>

Use this option to set the path to the temporary directory used for rewriting. When applying a tree filter, the command needs to temporarily check out the tree to some directory, which may consume considerable space in case of large projects. By default it does this in the .git-rewrite/ directory but you can override that choice by this parameter.書き換えに使用する一時ディレクトリへのパスを設定するには、このオプションを使用します。ツリーフィルタを適用するとき、コマンドは一時的にツリーをあるディレクトリにチェックアウトする必要があります。これは大きなプロジェクトの場合にかなりのスペースを消費する可能性があります。デフォルトでは.git-rewrite /ディレクトリでこれを行いますが、このパラメータでその選択を上書きすることができます。

-f

--force - 力

git filter-branch refuses to start with an existing temporary directory or when there are already refs starting with refs/original/, unless forced.強制されない限り、git filter-branchは既存の一時ディレクトリからの開始を拒否するか、すでにrefs / original /で始まる参照がある場合は拒否します。

--state-branch <branch>

This option will cause the mapping from old to new objects to be loaded from named branch upon startup and saved as a new commit to that branch upon exit, enabling incremental of large trees. If <branch> does not exist it will be created.このオプションにより、起動時に古いオブジェクトから新しいオブジェクトへのマッピングが名前付きブランチからロードされ、終了時にそのブランチへの新しいコミットとして保存され、大きなツリーの増分を可能にします。場合<枝>が存在しない、それが作成されます。

<rev-list options>… <rev-list options>…

Arguments for git rev-list. All positive refs included by these options are rewritten. You may also specify options such as --all, but you must use -- to separate them from the git filter-branch options. Implies Remap to ancestor.引数のgit REV-リスト。これらのオプションに含まれるすべての肯定的な参照は書き直されます。などのオプションを指定することもできます--allが、--それらをgit filter-branchオプションから分離するために使用する必要があります。意味先祖に再マップを。

Remap to ancestor先祖へのリマップ

By using git-rev-list[1] arguments, e.g., path limiters, you can limit the set of revisions which get rewritten. However, positive refs on the command line are distinguished: we don’t let them be excluded by such limiters. For this purpose, they are instead rewritten to point at the nearest ancestor that was not excluded.パスリミッターなどのgit-rev-list [1]引数を使用することで、書き換えられるリビジョンのセットを制限することができます。ただし、コマンドラインでの肯定的な参照は区別されています。それらをそのような制限によって除外させないでください。この目的のために、それらは除外されなかった最も近い祖先を指すように代わりに書き直されます。

EXIT STATUS終了ステータス

On success, the exit status is 0. If the filter can’t find any commits to rewrite, the exit status is 2. On any other error, the exit status may be any other non-zero value.成功した場合、終了ステータスはになり0ます。フィルタが書き換えるコミットを見つけられない場合、終了ステータスはになり2ます。その他のエラーが発生した場合、終了ステータスは他のゼロ以外の値になることがあります。

EXAMPLES例

Suppose you want to remove a file (containing confidential information or copyright violation) from all commits:すべてのコミットからファイル（機密情報または著作権侵害を含む）を削除したいとします。

git filter-branch --tree-filter 'rm filename' HEAD

However, if the file is absent from the tree of some commit, a simple rm filename will fail for that tree and commit. Thus you may instead want to use rm -f filename as the script.しかし、ファイルがコミットのツリーに存在しrm filenameない場合、そのツリーとコミットに対して単純なものは失敗します。したがって、代わりrm -f filenameにスクリプトとして使用したいと思うかもしれません。

Using --index-filter with git rm yields a significantly faster version. Like with using rm filename, git rm --cached filename will fail if the file is absent from the tree of a commit. If you want to "completely forget" a file, it does not matter when it entered history, so we also add --ignore-unmatch:git rmと--index-filter一緒に使用すると、かなり速いバージョンが得られます。使用したと同じように、ファイルがコミットの木に存在しない場合に失敗します。ファイルを「完全に忘れる」場合は、いつファイルが履歴に入ったかは関係ありません。rm filenamegit rm --cached filename--ignore-unmatch

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

Now, you will get the rewritten history saved in HEAD.これで、書き換えられた履歴がHEADに保存されます。

To rewrite the repository to look as if foodir/ had been its project root, and discard all other history:foodir/プロジェクトのルートであるかのようにリポジトリを書き換えて、他のすべての履歴を破棄するには、次の手順に従います。

git filter-branch --subdirectory-filter foodir -- --all

Thus you can, e.g., turn a library subdirectory into a repository of its own. Note the -- that separates filter-branch options from revision options, and the --all to rewrite all branches and tags.したがって、たとえば、ライブラリのサブディレクトリを独自のリポジトリに変えることができます。--これはフィルタブランチオプションとリビジョンオプションを分けることと、--allすべてのブランチとタグを書き換えることに注意してください。

To set a commit (which typically is at the tip of another history) to be the parent of the current initial commit, in order to paste the other history behind the current history:現在の履歴の後ろに他の履歴を貼り付けるために、コミット（通常は別の履歴の先端にある）を現在の初期コミットの親に設定するには、次のようにします。

git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD

(if the parent string is empty - which happens when we are dealing with the initial commit - add graftcommit as a parent). Note that this assumes history with a single root (that is, no merge without common ancestors happened). If this is not the case, use:（親文字列が空の場合 - これは最初のコミットを処理しているときに発生します - 親としてgraftcommitを追加します）。これは単一のルートを持つ履歴を仮定していることに注意してください（つまり、共通の先祖なしのマージは行われません）。そうでない場合は、次のようにします。

git filter-branch --parent-filter \
	'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD

or even simpler:あるいはもっと簡単です。

git replace --graft $commit-id $graft-id
git filter-branch $graft-id..HEAD

To remove commits authored by "Darl McBribe" from the history:"Darl McBribe"によって作成されたコミットを履歴から削除するには：

git filter-branch --commit-filter '
	if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
	then
		skip_commit "$@";
	else
		git commit-tree "$@";
	fi' HEAD

The function skip_commit is defined as follows:関数skip_commitは次のように定義されています。

skip_commit()
{
	shift;
	while [ -n "$1" ];
	do
		shift;
		map "$1";
		shift;
	done;
}

The shift magic first throws away the tree id and then the -p parameters. Note that this handles merges properly! In case Darl committed a merge between P1 and P2, it will be propagated properly and all children of the merge will become merge commits with P1,P2 as their parents instead of the merge commit.shiftマジックは最初にツリーIDを捨ててから-pパラメータを捨てます。これは正しくマージを処理することに注意してください。DarlがP1とP2の間でマージをコミットした場合、それは適切に伝播され、マージのすべての子はマージコミットではなくP1、P2を親とするマージコミットになります。

NOTE the changes introduced by the commits, and which are not reverted by subsequent commits, will still be in the rewritten branch. If you want to throw out changes together with the commits, you should use the interactive mode of git rebase.注コミットによって導入された変更を、その後のコミットによって逆戻りされていない、まだ書き換えブランチになります。コミットと一緒に変更を捨てたいのなら、対話モードのgit rebaseを使うべきです。

You can rewrite the commit log messages using --msg-filter. For example, git svn-id strings in a repository created by git svn can be removed this way:コミットログメッセージを書き換えることができます--msg-filter。例えば、gitのSVN-IDとによって作成されたリポジトリ内の文字列のGit SVNはこの方法で除去することができます。

git filter-branch --msg-filter '
	sed -e "/^git-svn-id:/d"
'

If you need to add Acked-by lines to, say, the last 10 commits (none of which is a merge), use this command:最後の10コミットにAcked-byの行を追加する必要がある場合（どれもマージではありません）、次のコマンドを使用します。

git filter-branch --msg-filter '
	cat &&
	echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
' HEAD~10..HEAD

The --env-filter option can be used to modify committer and/or author identity. For example, if you found out that your commits have the wrong identity due to a misconfigured user.email, you can make a correction, before publishing the project, like this:この--env-filterオプションは、コミッターまたは作成者のIDを変更するために使用できます。たとえば、user.emailの設定が誤っているためにコミットのIDが間違っていることがわかった場合は、プロジェクトを公開する前に、次のように修正を加えることができます。

git filter-branch --env-filter '
	if test "$GIT_AUTHOR_EMAIL" = "root@localhost"
	then
		GIT_AUTHOR_EMAIL=john@example.com
	fi
	if test "$GIT_COMMITTER_EMAIL" = "root@localhost"
	then
		GIT_COMMITTER_EMAIL=john@example.com
	fi
' -- --all

To restrict rewriting to only part of the history, specify a revision range in addition to the new branch name. The new branch name will point to the top-most revision that a git rev-list of this range will print.履歴の一部だけに書き換えを制限するには、新しいブランチ名に加えて改訂範囲を指定します。新しいブランチ名は、この範囲のgit rev-listが出力する一番上のリビジョンを指します。

Consider this history:この歴史を考えてみましょう：

     D--E--F--G--H
    /     /
A--B-----C

To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use:D、E、F、G、Hのコミットのみを書き換え、A、B、Cはそのままにするには、次のようにします。

git filter-branch ... C..H

To rewrite commits E,F,G,H, use one of these:コミットE、F、G、Hを書き換えるには、以下のいずれかを使用します。

git filter-branch ... C..H --not D
git filter-branch ... D..H --not C

To move the whole tree into a subdirectory, or remove it from there:ツリー全体をサブディレクトリに移動するか、そこから削除します。

git filter-branch --index-filter \
	'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
		GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
			git update-index --index-info &&
	 mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD

CHECKLIST FOR SHRINKING A REPOSITORYリポジトリを縮小するためのチェックリスト

git-filter-branch can be used to get rid of a subset of files, usually with some combination of --index-filter and --subdirectory-filter. People expect the resulting repository to be smaller than the original, but you need a few more steps to actually make it smaller, because Git tries hard not to lose your objects until you tell it to. First make sure that:gitのフィルタ分岐は通常、いくつかの組み合わせで、ファイルのサブセットを取り除くために使用することができます--index-filterと--subdirectory-filter。結果として得られるリポジトリは元のものより小さくなると人々は予想していますが、実際にそれを小さくするには、Gitが指示するまでオブジェクトを失うことがないようにするためにさらにいくつかの手順が必要です。まず次のことを確認してください。

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.BLOBがその存続期間にわたって移動された場合、あなたは本当にファイル名のすべての変種を削除しました。git log --name-only --follow --all -- filename名前の変更を見つけるのに役立ちます。
You really filtered all refs: use --tag-name-filter cat -- --all when calling git-filter-branch.あなたは本当にすべての参照をフィルタリングしました：--tag-name-filter cat -- --allgit-filter-branchを呼び出すときに使います。

Then there are two ways to get a smaller repository. A safer way is to clone, that keeps your original intact.それから、より小さなリポジトリを取得する2つの方法があります。より安全な方法はクローンを作成することです。

Clone it with git clone file:///path/to/repo. The clone will not have the removed objects. See git-clone[1]. (Note that cloning with a plain path just hardlinks everything!)でクローンしgit clone file:///path/to/repoます。クローンは削除されたオブジェクトを持ちません。git-clone [1]を参照してください。（普通のパスでクローンを作成すると、すべてがハードリンクされるだけです）。

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.git-filter-branchでバックアップされた元の参照を削除します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.ですべてのreflogを期限切れにしgit reflog expire --expire=now --allます。
Garbage collect all unreferenced objects with git gc --prune=now (or if your git-gc is not new enough to support arguments to --prune, use git repack -ad; git prune instead).参照されていないすべてのオブジェクトをでガベージコレクションしますgit gc --prune=now（またはgit-gcが引数をサポートするほど新しくない場合は--prune、git repack -ad; git prune代わりに使用します）。

NOTESノート

git-filter-branch allows you to make complex shell-scripted rewrites of your Git history, but you probably don’t need this flexibility if you’re simply removing unwanted data like large files or passwords. For those operations you may want to consider The BFG Repo-Cleaner, a JVM-based alternative to git-filter-branch, typically at least 10-50x faster for those use-cases, and with quite different characteristics:git-filter-branchを使用すると、Gitの履歴をシェルスクリプトで複雑に書き換えることができますが、大きなファイルやパスワードなどの不要なデータを単純に削除するのであれば、この柔軟性は不要です。そのような操作には、git-filter-branchに代わるJVMベースの代替案であるBFG Repo-Cleanerを検討することをお勧めします。これらのユースケースでは通常少なくとも10～50倍高速で、まったく異なる特性があります。

Any particular version of a file is cleaned exactly once. The BFG, unlike git-filter-branch, does not give you the opportunity to handle a file differently based on where or when it was committed within your history. This constraint gives the core performance benefit of The BFG, and is well-suited to the task of cleansing bad data - you don’t care where the bad data is, you just want it gone.ファイルの特定のバージョンは、一度だけ消去されます。BFGは、git-filter-branchとは異なり、履歴のどこでいつコミットされたかに基づいてファイルを異なる方法で処理する機会を与えません。この制約は、BFGのコア性能上の利益を与え、不良データをクレンジングするタスクに適している-あなたは気にしないところ悪いデータがあり、あなたはそれがしたいなくなって。
By default The BFG takes full advantage of multi-core machines, cleansing commit file-trees in parallel. git-filter-branch cleans commits sequentially (i.e. in a single-threaded manner), though it is possible to write filters that include their own parallelism, in the scripts executed against each commit.デフォルトでは、BFGはマルチコアマシンを最大限に活用し、コミットファイルツリーを並行してクレンジングします。git-filter-branchはコミットをシーケンシャルに（つまりシングルスレッドの方法で）クリーンアップしますが、各コミットに対して実行されるスクリプト内に独自の並列処理を含むフィルタを書くことは可能です。
The command options are much more restrictive than git-filter branch, and dedicated just to the tasks of removing unwanted data- e.g: --strip-blobs-bigger-than 1M.コマンドオプションは、はるかに制限はgit-フィルタ分岐よりも、ちょうど例えばDATA-不要の除去作業に専念します：--strip-blobs-bigger-than 1M。