public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg•org>
To: Wolfgang Faust <contrib-git@wolfgangfaust•com>
Cc: Birger Skogeng Pedersen <birger.sp@gmail•com>,
	Pratyush Yadav <me@yadavpratyush•com>,
	Marc Branchaud <marcnarc@xiplink•com>,
	git@vger•kernel.org, Junio C Hamano <gitster@pobox•com>
Subject: Re: [PATCH 0/4] run auto maintenance in git-gui
Date: Fri, 13 Mar 2026 13:38:57 +0100	[thread overview]
Message-ID: <7905c1d6-ae6e-4930-b4bf-d1129685d10f@kdbg.org> (raw)
In-Reply-To: <876fd32d-3965-4587-b567-399787741247@app.fastmail.com>

Am 11.03.26 um 05:48 schrieb Wolfgang Faust:
> However, it seems to me that the conditions you outlined are very
> unlikely.

This was the whole point of my argument.

> In particular:
> 
>> - They configure maintenance.* to do more cleanups than the default
>> confituration (which is the same as `git gc --auto`, I think).
>>
>> - They never use `git maintenance run` through some other facility.
> 
> Are these not more or less mutually exclusive? Why would someone set
> up maintenance to do things, and then never run maintenance?

The system configuration could be set to non-default values.

But it would need quite some determination from a user to side-step any
and all explicit and implicit `git maintenance` calls on such a system
instead of countermanding the configuration in the personal (global or
local) settings.

My point is only that these conditions aren't mutually exclusive, but
still unlikely in practice.

> Given the above, I see two options:
> 
> 1. Assume that in practice everybody wants auto maintenance and
>    `gui.gcwarning` is set because they were annoyed by the dialog.
> 2. Assume that some people do *not* want auto maintenance, and if the
>    `gui.gcmaintenance` option is unset then show some kind of dialog
>    that tries to explain the situation to the user and encourages them
>    to set `gui.gcmaintenance=auto`.
> 
> #2 is the safer option, but is rather complicated and involves
> bothering every user for the sake of strict compatibility. I assume
> that git core itself had to make a similar tradeoff when deciding to
> enable automatic garbage collection, but I don't know where I'd find
> that discussion and perhaps it's far enough in the past that the
> rationales are no longer relevant anyway.

Let's just call `git maintenance` on every commit except when, for
legacy reasons, gui.gcwarning is false. No new configuration, please,
until there is proof that Git GUI users really do not want the standard
`git maintenance` behavior.

-- Hannes


  reply	other threads:[~2026-03-13 12:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 17:31 git-gui: disable the "loose objects popup" dialog? Birger Skogeng Pedersen
2019-09-26 18:54 ` Johannes Sixt
2019-09-26 19:13   ` Birger Skogeng Pedersen
2019-09-26 19:15   ` Pratyush Yadav
2019-09-26 21:12     ` Birger Skogeng Pedersen
2019-09-26 21:13     ` Johannes Sixt
2019-10-01 18:00       ` Pratyush Yadav
2019-10-02  7:12         ` Birger Skogeng Pedersen
2019-10-02 18:48         ` Johannes Sixt
2026-03-06  5:15           ` [PATCH 0/4] run auto maintenance in git-gui Wolfgang Faust
2026-03-06  5:26             ` [PATCH 1/4] git-gui: run auto maintenance on commit Wolfgang Faust
2026-03-06  5:30             ` [PATCH 2/4] git-gui: remove hint_gc dialog Wolfgang Faust
2026-03-06  5:32             ` [PATCH 3/4] git-gui: remove "Compress Database" feature Wolfgang Faust
2026-03-06  5:32             ` [PATCH 4/4] scalar: remove obsolete gui.GCWarning setting Wolfgang Faust
2026-03-07 11:32             ` [PATCH 0/4] run auto maintenance in git-gui Johannes Sixt
2026-03-07 22:01               ` Junio C Hamano
2026-03-07 22:37                 ` Johannes Sixt
2026-03-08  6:02                   ` Junio C Hamano
2026-03-11  4:48                   ` Wolfgang Faust
2026-03-13 12:38                     ` Johannes Sixt [this message]
2019-10-02 20:41         ` git-gui: disable the "loose objects popup" dialog? Marc Branchaud
2019-09-26 21:14     ` Marc Branchaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7905c1d6-ae6e-4930-b4bf-d1129685d10f@kdbg.org \
    --to=j6t@kdbg$(echo .)org \
    --cc=birger.sp@gmail$(echo .)com \
    --cc=contrib-git@wolfgangfaust$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=marcnarc@xiplink$(echo .)com \
    --cc=me@yadavpratyush$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox