From: Thomas Rast <trast@student.ethz.ch>
To: git@vger.kernel.org
Cc: "Jan Krüger" <jk@jk.gs>,
"Johannes Schindelin" <johannes.schindelin@gmx.de>,
"Junio C Hamano" <gitster@pobox.com>
Subject: [PATCH v2] Documentation: pruning recipe for destructive filter-branch
Date: Sat, 14 Feb 2009 15:22:08 +0100 [thread overview]
Message-ID: <1234621328-8998-1-git-send-email-trast@student.ethz.ch> (raw)
In-Reply-To: <alpine.DEB.1.00.0902141248220.10279@pacific.mpi-cbg.de>
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>
---
Johannes Schindelin wrote:
> On Sat, 14 Feb 2009, Jan Krüger wrote:
>
> > Subject: [PATCH] gc: add --prune-expire option equivalent to gc.pruneExpire
>
> I like it, and if nobody beats me to it, I will add a test for this
> option tonight.
Cool, then let's use that in the docs.
Documentation/git-filter-branch.txt | 36 +++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 1fbbbb4..d148e58 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -339,6 +339,42 @@ 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`. 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`).
+
+
Author
------
Written by Petr "Pasky" Baudis <pasky@suse.cz>,
--
1.6.2.rc0.283.g181d4
next prev parent reply other threads:[~2009-02-14 14:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-13 17:14 [PATCH] Documentation: pruning recipe for destructive filter-branch Thomas Rast
2009-02-14 1:07 ` Junio C Hamano
2009-02-14 1:51 ` Jan Krüger
2009-02-14 5:46 ` Johannes Schindelin
2009-02-14 6:49 ` Jan Krüger
2009-02-14 11:48 ` Johannes Schindelin
2009-02-14 14:22 ` Thomas Rast [this message]
2009-02-14 19:12 ` [PATCH v2] " Johannes Schindelin
2009-02-14 19:29 ` Junio C Hamano
2009-02-14 20:56 ` [PATCH v3] " Thomas Rast
2009-02-14 19:02 ` [PATCH] gc: make --prune useful again by accepting an optional parameter Johannes Schindelin
2009-02-14 21:33 ` Thomas Rast
2009-02-14 21:33 ` Jan Krüger
2009-02-14 22:05 ` Johannes Schindelin
2009-02-14 22:10 ` [PATCH v2] " Johannes Schindelin
2009-02-14 22:38 ` Thomas Rast
2009-02-15 19:33 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1234621328-8998-1-git-send-email-trast@student.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jk@jk.gs \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).