Re: [PATCH v4 07/14] builtin/config: introduce "list" subcommand

From: Patrick Steinhardt <ps@pks.im>
Date: May 6, 2024, 07:51 UTC
Message-ID: <ZjiL7vu5kCVwpsLd@tanuki>
In-Reply-To: <xmqqjzkaanr1.fsf@gitster.g>

On Fri, May 03, 2024 at 09:01:06AM -0700, Junio C Hamano wrote:

Show 20 quoted lines

> <rsbecker@nexbridge.com> writes:
> 
> >>> +DEPRECATED MODES
> >>> +----------------
> >>> +
> >>> +The following modes have been deprecated in favor of subcommands. It
> >>> +is recommended to migrate to the new syntax.
> >>> +
> >>> +-l::
> >>> +--list::
> >>> +	Replaced by `git config list`.
> 
> Can you trim quotes in your response that has no relevance to what
> you are responding to?
> 
> > Removing the --list option is going to break backward
> > compatibility for users who script the use of config for things
> > like setup, clone automation, etc.
> 
> Yes, that is why this is merely a deprecation.

I will probably send a follow-up patch series that converts other tests to use the new syntax and that does some more cleanups. I was pondering whether we want to introduce a document as part of that patch series that starts to keep track of upcoming removals for a potential Git 3.0 release.

There are multiple items that could be added:

  - Removal of the old syntax of git-config(1).

  - Removal of the dumb HTTP transport.

  - Removal of `info/grafts`.

There are probably other items.

In any case, the old actions are here to stay for the foreseeable future until we commit to a breaking major release.

Show 29 quoted lines

> > Adding list as a sub-command could (but should not) cause
> > ambiguities between a list and configuration value.
> 
> Because there is no sectionless variable, there exists no ambiguity.
> 
> In other words,
> 
>     $ git config list
> 
> cannot be asking for the value of the variable "list", because such
> a variable cannot exist.  When you start your command with
> 
>     $ git config list ...
> 
> whatever other tokens follow that token "list" on the command line,
> it is a "--list" subcommand.  A traditional and lazy "get a single
> variable" without an explicit subcommand would look like
> 
>     $ git config section.variable
> 
> that is a short-hand to
> 
>     $ git config --get section.variable
> 
> and would become
> 
>     $ git config get section.variable
> 
> in the new world order.

Thanks for the thorough explanation, I have nothing to add!

Patrick