Skip to content

Commit

Permalink
Documentation: pruning recipe for destructive filter-branch
Browse files Browse the repository at this point in the history
Add a section about how to shrink a repository's size after running
git-filter-branch to remove large blobs from history.

This comes up every week or so on IRC, and the commands required to
handle every case are not very newbie-friendly, so hopefully writing
them down somewhere leads to fewer questions.

It may seem contradictory to document fallbacks for older Gits in
newer docs, but we want to point people at this as a FAQ answer, and
they will frequently not have the newest version installed.

Thanks to Björn Steinbrink and Junio C Hamano for comments and
corrections.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
  • Loading branch information
Thomas Rast authored and Junio C Hamano committed Feb 15, 2009
1 parent e9cc02f commit d0268de
Showing 1 changed file with 41 additions and 0 deletions.
41 changes: 41 additions & 0 deletions Documentation/git-filter-branch.txt
Original file line number Diff line number Diff line change
Expand Up @@ -339,6 +339,47 @@ git filter-branch --index-filter \
---------------------------------------------------------------



Checklist for Shrinking a Repository
------------------------------------

git-filter-branch is often 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:

* 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.

* You really filtered all refs: use `\--tag-name-filter cat \--
\--all` when calling git-filter-branch.

Then there are two ways to get a smaller repository. A safer way is
to clone, that keeps your original intact.

* 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=now`
(or if your git-gc is not new enough to support arguments to
`\--prune`, use `git repack -ad; git prune` instead).


Author
------
Written by Petr "Pasky" Baudis <pasky@suse.cz>,
Expand Down

0 comments on commit d0268de

Please sign in to comment.