Improve support for 'git config gc.reflogExpire never'

Improve support for 'git config gc.reflogExpire never'

[Mikko Rantalainen]

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.


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.

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".


Discussion about this case:
https://stackoverflow.com/questions/28092485/how-to-prevent-garbage-collection-in-git
https://stackoverflow.com/questions/55043693/is-it-possible-to-get-git-gc-to-pack-reflog-objects

-- 
Mikko

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

[Jeff King]

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

> 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

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

[Ævar Arnfjörð Bjarmason]

On Fri, Mar 08 2019, Mikko Rantalainen wrote:

> 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.
>
>
> 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.
>
> 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".
>
>
> Discussion about this case:
> https://stackoverflow.com/questions/28092485/how-to-prevent-garbage-collection-in-git
> https://stackoverflow.com/questions/55043693/is-it-possible-to-get-git-gc-to-pack-reflog-objects

Just to add to Jeff's E-Mail, the case he's describing is something I
wrote a stand-alone test case for here:
https://public-inbox.org/git/87fu6bmr0j.fsf@evledraar.gmail.com/

Try to run it, it's probably the same behavior you're seeing, and it has
nothing per-se to do with reflogs.