Re: [PATCH 0/4] run auto maintenance in git-gui
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Mar 7, 2026, 22:37 UTC
- Message-ID
- <40ccd060-e6f7-4130-a25e-3c2f65df8eb7@kdbg.org>
- In-Reply-To
- <xmqqms0jti24.fsf@gitster.g>
Am 07.03.26 um 23:01 schrieb Junio C Hamano:
Show 19 quoted lines
> Johannes Sixt <j6t@kdbg.org> writes: > >> However, the consequences for users need to be considered. You replace >> the custom implementation of `git gc` with `git maintenance run --auto`. >> The latter CAN do a lot more than the former. It turns out, that Git GUI >> already calls into `git maintance` indirectly via `git merge` and `git >> fetch`. So, users who set gui.gcwarning to false (myself included) were >> already prone to occasional inadvertent cleanups. >> >> So, users that are hurt by this new change are those where all these >> conditions are true: >> ... >> How many could this be? Not many, I guess. The conservative safe >> approach would be to treat gui.gcwarning=false as an indication that >> automatic cleanup is not desired. > > Hmph, if you are _declining_ to see the warning, isn't it a sign > that you are getting these warnings and got annoyed enough to find > out about the settings and turned it to "false" to squelch?
The option does not only control whether or not a warning appears, but also whether garbage collection happens or not. When it is set to false, then in addition to squelching the warning, garbage collection does *not* happen. The option is on by default, so if we find it off, the user must have set it explicitly, a clear sign (IMO) that Git GUI should not do the garbage collection.
> And if > we make pruning more aggressive, wouldn't gui.gcwarning explicitly > set to false be a sign that you'd be more likely to be in the > affected poulation?
I think so, too. For this reason, my implied suggestion was to protect the new call of `git maintenance` with a check whether gui.gcwarning is enabled. Then we don't make anything worse for those who have it disabled.
-- Hannes