Thread (11 messages) flat view 11 messages, 9 authors, 2016-06-15
STALE3753d

[PATCH] objects to be pruned immediately don't have to be loosened

From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:45:46
Subsystem: documentation, the rest · Maintainers: Jonathan Corbet, Linus Torvalds

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 <redacted>
---

On Mon, 15 Dec 2008, Theodore Tso wrote:
On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
quoted
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]);
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help