git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: "There are too many unreachable loose objects" - why don't we run 'git prune' automatically?

From
Lars Schneider <larsxschneider@gmail.com>
Date
Jun 9, 2017, 12:03 UTC
Message-ID
<7497DFA7-3F4E-4DB2-B31B-FDDEB2F30BB8@gmail.com>
In-Reply-To
<20170609052755.dsuqd4gizi2opoya@sigill.intra.peff.net>
Show 36 quoted lines
> On 09 Jun 2017, at 07:27, Jeff King <peff@peff.net> wrote:
> 
> On Thu, Jun 08, 2017 at 02:45:48PM +0200, Lars Schneider wrote:
> 
>> I recently ran into "There are too many unreachable loose objects; run 
>> 'git prune' to remove them." after a "Auto packing the repository in 
>> background for optimum performance." message.
>> 
>> This was introduced with a087cc9 "git-gc --auto: protect ourselves from 
>> accumulated cruft" but I don't understand the commit message really.
>> 
>> Why don't we call 'git prune' automatically? I though Git would prune
>> unreachable objects after 90 days by default anyways. Is the warning 
>> about unreachable objects that are not yet 90 days old?
> 
> We _do_ call "git prune", but we do so with whatever configured
> expiration time is (by default 2 weeks; the 90-day expiration is for
> reflogs).
> 
> The problem is that auto-gc kicked in because there were a bunch of
> loose objects, but after repacking and running "git prune" there were
> still enough loose objects to trigger auto-gc. Which means every command
> you run will do an auto-gc that never actually helps.
> 
> So you have two options:
> 
>  1. Wait until those objects expire (which may be up to 2 weeks,
>     depending on how recent they are), at which point your auto-gc will
>     finally delete them.
> 
>  2. Run "git prune". Without an argument it prunes everything now,
>     with no expiration period.
> 
> I agree the existing message isn't great. There should probably be a big
> advise() block explaining what's going on (and that expert users can
> disable).
How about this?
diff --git a/builtin/gc.c b/builtin/gc.c
index c2c61a57bb..12ee212544 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -473,9 +473,18 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
 	if (pack_garbage.nr > 0)
 		clean_pack_garbage();
 
-	if (auto_gc && too_many_loose_objects())
-		warning(_("There are too many unreachable loose objects; "
-			"run 'git prune' to remove them."));
+	if (auto_gc && too_many_loose_objects()) {
+		warning(_("Auto packing did not lead to optimal results as the "
+			"repository contains too many unreachable objects."));
+		advice(_("Unreachable objects are Git objects (commits, files, ...) "
+			"that are not referenced by any branch or tag. This might happen "
+			"if you use 'git rebase' or if you delete branches. Auto packing "
+			"only prunes unreachable objects that are older than 2 weeks "
+			"(default, overridable by the config variable 'gc.pruneExpire'). "
+			"Please run 'git prune' to prune all unreachable objects for "
+			"optimal repository performance."));
+	}
 
 	if (!daemonized)
 		unlink(git_path("gc.log"));
- Lars
Previous: Jeff KingNext: Jeff King
Message 3 of 6 in “"There are too many unreachable loose objects" - why don't we run 'git prune' automatically?”
  1. Lars SchneiderJun 8, 2017
  2. Jeff KingJun 9, 2017
  3. Lars SchneiderJun 9, 2017
  4. Jeff KingJun 10, 2017
  5. Lars SchneiderJun 18, 2017
  6. Jeff KingJun 20, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.