| git-filter-branch(1) |
| ==================== |
| |
| NAME |
| ---- |
| git-filter-branch - Rewrite branches |
| |
| SYNOPSIS |
| -------- |
| [verse] |
| 'git-filter-branch' [--env-filter <command>] [--tree-filter <command>] |
| [--index-filter <command>] [--parent-filter <command>] |
| [--msg-filter <command>] [--commit-filter <command>] |
| [--tag-name-filter <command>] [--subdirectory-filter <directory>] |
| [--original <namespace>] [-d <directory>] [-f | --force] |
| [<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. |
| |
| The command will only rewrite the _positive_ refs mentioned in the |
| command line (i.e. 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. |
| |
| *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. |
| |
| 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/'. |
| |
| Note that since this operation is extensively 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. |
| |
| |
| Filters |
| ~~~~~~~ |
| |
| The filters are applied in the order as listed below. The <command> |
| argument is always evaluated in shell 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 set according to the current commit. |
| |
| 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. |
| |
| |
| OPTIONS |
| ------- |
| |
| --env-filter <command>:: |
| This is the filter for modifying the environment in which |
| the commit will be performed. Specifically, you might want |
| to rewrite the author/committer name/email/time environment |
| variables (see gitlink:git-commit[1] for details). Do not forget |
| to re-export the variables. |
| |
| --tree-filter <command>:: |
| 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*!). |
| |
| --index-filter <command>:: |
| 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. For hairy cases, see gitlink:git-update-index[1]. |
| |
| --parent-filter <command>:: |
| 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 |
| a format accepted by gitlink: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. |
| |
| --msg-filter <command>:: |
| 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>:: |
| This is the filter for performing the commit. |
| If this filter is specified, it will be called instead of the |
| gitlink:git-commit-tree[1] 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. |
| + |
| As a special extension, the commit filter may emit multiple |
| commit ids; in that case, ancestors of the original commit will |
| have all of them as parents. |
| + |
| 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 gitlink:git-rebase[1] instead). |
| |
| --tag-name-filter <command>:: |
| 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. |
| + |
| 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. |
| + |
| Note that there is currently no support for proper rewriting of |
| tag objects; in layman terms, if the tag has a message or signature |
| attached, the rewritten tag won't have it. Sorry. (It is by |
| definition impossible to preserve signatures at any rate.) |
| |
| --subdirectory-filter <directory>:: |
| Only look at the history which touches the given subdirectory. |
| The result will contain that directory (and only that) as its |
| project root. |
| |
| --original <namespace>:: |
| Use this option to set the namespace where the original commits |
| will be stored. The default value is 'refs/original'. |
| |
| -d <directory>:: |
| Use this option to set the path to the temporary directory used for |
| rewriting. When applying a tree filter, the command needs to |
| temporary checkout 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. |
| |
| -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. |
| |
| <rev-list-options>:: |
| When options are given after the new branch name, they will |
| be passed to gitlink:git-rev-list[1]. Only commits in the resulting |
| output will be filtered, although the filtered commits can still |
| reference parents which are outside of that set. |
| |
| |
| 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 |
| ------------------------------------------------------- |
| |
| A significantly faster version: |
| |
| -------------------------------------------------------------------------- |
| git filter-branch --index-filter 'git update-index --remove filename' HEAD |
| -------------------------------------------------------------------------- |
| |
| Now, you will get the rewritten history saved in HEAD. |
| |
| 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: |
| |
| -------------------------------------------------------------------------- |
| git filter-branch --parent-filter \ |
| 'cat; test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>"' HEAD |
| -------------------------------------------------------------------------- |
| |
| or even simpler: |
| |
| ----------------------------------------------- |
| echo "$commit-id $graft-id" >> .git/info/grafts |
| git filter-branch $graft-id..HEAD |
| ----------------------------------------------- |
| |
| To remove commits authored by "Darl McBribe" from the history: |
| |
| ------------------------------------------------------------------------------ |
| git filter-branch --commit-filter ' |
| if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ]; |
| then |
| skip_commit "$@"; |
| else |
| git commit-tree "$@"; |
| fi' HEAD |
| ------------------------------------------------------------------------------ |
| |
| The function 'skip_commits' is defined as follows: |
| |
| -------------------------- |
| 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. |
| |
| |
| 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. |
| |
| *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 gitlink:git-rebase[1]. |
| |
| |
| 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: |
| |
| -------------------------------- |
| git filter-branch ... C..H |
| -------------------------------- |
| |
| To rewrite commits E,F,G,H, use one of these: |
| |
| ---------------------------------------- |
| 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 |
| --------------------------------------------------------------- |
| |
| |
| Author |
| ------ |
| Written by Petr "Pasky" Baudis <pasky@suse.cz>, |
| and the git list <git@vger.kernel.org> |
| |
| Documentation |
| -------------- |
| Documentation by Petr Baudis and the git list. |
| |
| GIT |
| --- |
| Part of the gitlink:git[7] suite |