From: Nicolas Pitre <nico@cam.org>
To: Theodore Tso <tytso@mit.edu>
Cc: "Björn Steinbrink" <B.Steinbrink@gmx.de>,
"Mikael Magnusson" <mikachu@gmail.com>,
"Bruce Stephens" <bruce.stephens@isode.com>,
git@vger.kernel.org
Subject: [PATCH] objects to be pruned immediately don't have to be loosened
Date: Mon, 15 Dec 2008 12:38:02 -0500 (EST) [thread overview]
Message-ID: <alpine.LFD.2.00.0812151105100.30035@xanadu.home> (raw)
In-Reply-To: <20081215155610.GA11502@mit.edu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3331 bytes --]
When there is no grace period before pruning unreferenced objects, it is
pointless to push those objects in their loose form just to delete them
right away.
Also be more explicit about the possibility of using "now" in the
gc.pruneexpire config variable (needed for the above behavior to
happen).
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Mon, 15 Dec 2008, Theodore Tso wrote:
> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
> > so that git prune can drop them. And git gc invokes git prune so that
> > only unreachable objects older than 2 weeks are dropped.
>
> To be even more explicit, "git gc" will **unpack** objects that have
> become unreachable and were currently in packs. As a result, the
> amount of disk space used by a git repository can actually go **up**
> dramatically after a "git gc" operation, which could be surprising for
> someone who is running close to full on their filesystem, deletes a
> number of branches from a tracking repository, and then does a "git
> gc" may get a very unpleasant surprise.
>
> A really good repository which shows this is linux-next, since it is
> constantly getting rewound, and old branches are reserved via a tag
> such as next-20081204. If you update the your local copy of the
> linux-next repository every day, you will accumulate a large number of
> these old branch tags. If you then delete a whole series of them, and
> run git-gc, the operation will take quite a while, and the number of
> blocks and inodes used will grow significantly. They will disappear
> after a "git prune", but when I do this housekeeping operation, I've
> often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
> just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
> option to "git gc".
What about this?
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 21ea165..ca45e71 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -702,7 +702,9 @@ gc.packrefs::
gc.pruneexpire::
When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
- Override the grace period with this config variable.
+ Override the grace period with this config variable. The value
+ "now" may be used to disable this grace period and always prune
+ unreachable objects immediately.
gc.reflogexpire::
'git-reflog expire' removes reflog entries older than
diff --git a/builtin-gc.c b/builtin-gc.c
index 781df60..f8eae4a 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -188,7 +188,9 @@ static int need_to_gc(void)
* there is no need.
*/
if (too_many_packs())
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
else if (!too_many_loose_objects())
return 0;
@@ -243,7 +245,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
"run \"git gc\" manually. See "
"\"git help gc\" for more information.\n");
} else
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
return error(FAILED_RUN, argv_pack_refs[0]);
prev parent reply other threads:[~2008-12-15 17:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-15 12:52 "git gc" doesn't seem to remove loose objects any more Bruce Stephens
2008-12-15 13:38 ` Mikael Magnusson
2008-12-15 14:08 ` Bruce Stephens
2008-12-15 14:08 ` Björn Steinbrink
2008-12-15 15:56 ` Theodore Tso
2008-12-15 16:12 ` Mark Brown
2008-12-15 16:59 ` Johan Herland
2008-12-15 16:59 ` Mikael Magnusson
2008-12-15 17:07 ` Jakub Narebski
2008-12-15 19:38 ` Theodore Tso
2008-12-15 17:11 ` Brandon Casey
2008-12-15 17:38 ` Nicolas Pitre [this message]
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=alpine.LFD.2.00.0812151105100.30035@xanadu.home \
--to=nico@cam.org \
--cc=B.Steinbrink@gmx.de \
--cc=bruce.stephens@isode.com \
--cc=git@vger.kernel.org \
--cc=mikachu@gmail.com \
--cc=tytso@mit.edu \
/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).