Compress dialog popping up every time the repo is opened

[mh-tp]

It always shows up with the same amount of loose objects. The directory of the repo is in user space. It tried to fix it with upgrading the git gui version (2,32.0 64bit -> 2.36.1 64bit), but it only change the shown number. On the first compression run after the upgrade, it showed some progress/success, but after that the progress window (the one after deciding to compress) has always been empty.

So, I tried once again solving by upgrading to 2.37.0 (without checking the changelog to see, if it is reasonable to believe), something might have changed. It didn't help either.

My repo is a python project. I'm using only pycharm as IDE. I rarely used the git features of the IDE itself. The repo has about 250 commits, only 2 branches and about 5 MB project storage. I'm the only person pushing to the repo, rarely from other machines. Anything else I missed?

[PhilipOakley]

The code for this check is in \git\git-gui\lib\database.tcl #L91-115 or here

proc hint_gc {} {
	set ndirs 1
	set limit 8
	if {[is_Windows]} {
		set ndirs 4
		set limit 1
	}

	set count [llength [glob \
		-nocomplain \
		-- \
		[gitdir objects 4\[0-[expr {$ndirs-1}]\]/*]]]

	if {$count >= $limit * $ndirs} {
		set objects_current [expr {$count * 256/$ndirs}]
		if {[ask_popup \
			[mc "This repository currently has approximately %i loose objects.

To maintain optimal performance it is strongly recommended that you compress the database.

Compress the database now?" $objects_current]] eq yes} {
			do_gc
		}
	}
}

It uses a heuristic (if I understand correctly) to estimate the total size of the loose object database, and another for how big it should be based on the number of directories.

tcl is fairly simple once you get past the [] and {} meanings for when they evaluate/substitute (implicit JIT compiling ;-).

The database statistics are available (code from the same file) via the Repository -> Database Statistic menu at top left.

See if there are better tweaked values for settings?

[mh-tp]

Thanks for checking the source code. I tried to find any of those values within the settings, but there's nothing related I think. But I also found the option "Verify database". Doing so gave

567 x dangling blob
2 x dangling commit

I think cloning the repo from remote might finally fix the issue. I will report

[PhilipOakley]

The original code for those checks is 2009, so about 13 years old. There has been a lot of updates in the main Git code since then, so it's probably a poor heuristic.

Having thought overnight, I suspect that it could be either loose objects that won't pack, or need pruning, or some reflog or expiry mechanism keeps 'freshening' their last usage dates, so the old 'garbage' isn't disappearing fast enough. Maybe try compressing the database from the Gui menu to see if is helpful, along with expiring old object at less that the normal 30 days, maybe even expire=now, before pruning the data base.

[olsner]

From the manpage for git gc: "When common porcelain operations that create objects are run, they will check whether the repository has grown substantially since the last maintenance, and if so run git gc automatically."

I think that means that this feature could simply be removed from git gui - unless git-gui bypasses that check when it runs operations that create objects, gc already runs when necessary and there would be no need for git gui to ever suggest a gc.

If we really need to explicitly trigger git gc from git-gui, I think that should be done by always running git gc --auto on startup and let that check the amount of loose objects and gc if necessary. (Though we would like to avoid popping up the gc output window every startup... Maybe we could show it after the first output line from git gc or something like that.)

Edit: Looks like this has been discussed elsewhere reaching a similar conclusion - see e.g. #9.