On Wed, Jan 08, 2025 at 09:09:28AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> writes:
>
> > On Tue, Jan 07, 2025 at 11:55:16AM -0500, rsbecker@xxxxxxxxxxxxx wrote:
> >
> >> I like this but wonder whether there might be some way to inhibit the
> >> warnings one a user gets it and decides they will act but do not want
> >> to see the warnings any longer? I have had requests like this on other
> >> products. Just a thought.
> >
> > I guess the best idea I have here is to use an environment variable,
> > e.g. "GIT_ALLOW_DEPRECATED_REMOTES=true", along with a hint for how to
> > enable it.
>
> Hmph.
>
> I may be missing something, but wouldn't the whole point of the
> warning be noisy and pesky as long as the user _uses_ that
> configuration? It is not like "you can set this knob and delay the
> removal past Git 3.0". If the user migrates away from the mechanism
> that is being removed, we would stop bugging the user about the
> stale setting, so I do not see why we want to add anything extra
> (other than possibly telling them how to migrate away from
> $GIT_DIR/{branches,remotes}/ using "git remote" in the warning
> message itself).
Sure, that would be the intent. But it may take the user a bit of time
to do the migration, and meanwhile they may want to silence the warning.
It's not like we'll release Git 3.0 tomorrow, it will probably take us a
while to get there, which gives people a bit of time to migrate.
I'm also happy to just leave it out though, I don't mind too much.
Patrick
