Re: [PATCH v2 5/5] remote: announce removal of "branches/" and "remotes/"
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Jan 9, 2025, 10:06 UTC
- Message-ID
- <Z3-fnHV3nOMa1EPZ@pks.im>
- In-Reply-To
- <xmqqwmf5mdvb.fsf@gitster.g>
On Wed, Jan 08, 2025 at 09:09:28AM -0800, Junio C Hamano wrote:
Show 24 quoted lines
> Patrick Steinhardt <ps@pks.im> writes:
>
> > On Tue, Jan 07, 2025 at 11:55:16AM -0500, rsbecker@nexbridge.com 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