Re: Improve support for 'git config gc.reflogExpire never'

From: Jeff King <peff@peff.net>
Date: Mar 19, 2019, 06:47 UTC
Message-ID: <20190319064711.GD31801@sigill.intra.peff.net>
In-Reply-To: <39a0796a-7220-1e81-e7fe-3bf7329ed7de@peda.net>

On Fri, Mar 08, 2019 at 10:27:11AM +0200, Mikko Rantalainen wrote:

Show 15 quoted lines

> If I configure bare repo with
> 
> git config gc.pruneExpire never
> git config gc.reflogExpire never
> 
> then git will never garbage collect any commit ever stored in the repo.
> This is what I want.
> 
> However, all commits referenced only via reflog are kept as loose
> objects and will not be included in packs. In long run this will cause
> 
> warning: There are too many unreachable loose objects; run 'git prune'
> to remove them.
> 
> and the performance of the repository will slowly decrease.

That's not what's supposed to happen. A normal git-gc (or directly running the "git repack" it spawns) should consider objects in reflogs reachable, and pack them as it would an object reachable from a ref. This has been the case since 63049292e0 (Teach git-repack to preserve objects referred to by reflog entries., 2006-12-18).

Just to double check: are you sure you have reflogs? They're not enabled by default in bare repos.

Another thing that may surprise you is that deleting a branch will delete its reflog (and then the objects are unreachable, and may be exploded loose).

> If I have understood correctly, git should notice that reflog will keep
> referenced commits forever and include all those commits in packs
> instead of keeping those as loose forever.

Yes, that's what's supposed to happen. If you have a recipe for reproducing a case where it doesn't, I'd be curious to see it.

> A more generic behavior might be to always compress all loose commits in
> (one?) special pack so the performance would stay good even if
> gc.reflogExpire is very long instead of "never".

You can do "git repack -adk", which will keep all packed objects packed, and will suck up loose objects into the pack (and delete their loose counterparts). I don't think there's a convenient way to convince git-gc to do this when it runs "git repack", though. I think it would be a reasonable feature for it to have.

-Peff