From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: "Bence Ferdinandy" <bence@ferdinandy.com>,
"Justin Tobler" <jltobler@gmail.com>,
git@vger.kernel.org, "Heba Waly" <heba.waly@gmail.com>,
"Rubén Justo" <rjusto@gmail.com>
Subject: Re: [PATCH] advice: suggest using subcommand "git config set"
Date: Fri, 06 Dec 2024 11:23:42 +0900 [thread overview]
Message-ID: <xmqqplm51rdd.fsf@gitster.g> (raw)
In-Reply-To: <Z1FkrsQ5tkz1pFUz@pks.im> (Patrick Steinhardt's message of "Thu, 5 Dec 2024 09:30:38 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> Yeah. Overall I think it is fine to do an iterative transition to the
> new interface. `git config set` is not going to be the only instance
> that needs changes, but I very much assume that we will have suggestions
> and warnings all over the place that may recommend other modes of the
> command like the equivalent of `git config get`. But these don't have to
> all happen in the same commit, or even the same patch series, from my
> point of view.
>
> Thanks for working on this!
Exactly. We may have to keep both old and new (more explicit) ways
to spell the subcommand, and consistently using the new way in our
documentation pages and instruction given in advice messages is a
good thing, but it is more or less a clean-up effort we can do at
leisure ;-) As long as we make sure we finish before we mark the
old way deprecated, it is perfectly fine.
Thanks.
prev parent reply other threads:[~2024-12-06 2:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-04 13:08 [PATCH] advice: suggest using subcommand "git config set" Bence Ferdinandy
2024-12-04 17:19 ` Justin Tobler
2024-12-05 8:21 ` Bence Ferdinandy
2024-12-05 8:30 ` Patrick Steinhardt
2024-12-05 12:21 ` [PATCH v2] " Bence Ferdinandy
2024-12-06 8:57 ` Patrick Steinhardt
2024-12-08 8:08 ` Rubén Justo
2024-12-08 8:12 ` [PATCH 1/3] advice: enhance `detach_advice()` to `detach_advice_if_enabled()` Rubén Justo
2024-12-08 8:12 ` [PATCH 2/3] commit: use `advise_if_enabled()` in `read_graft_file()` Rubén Justo
2024-12-08 8:12 ` [PATCH 3/3] object-name: advice to avoid refs that resemble hashes Rubén Justo
2024-12-09 11:21 ` [PATCH v2] advice: suggest using subcommand "git config set" Bence Ferdinandy
2024-12-09 14:46 ` Bence Ferdinandy
2024-12-09 20:35 ` Rubén Justo
2024-12-11 8:52 ` Bence Ferdinandy
2024-12-11 18:00 ` Rubén Justo
2024-12-06 2:23 ` Junio C Hamano [this message]
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=xmqqplm51rdd.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=bence@ferdinandy.com \
--cc=git@vger.kernel.org \
--cc=heba.waly@gmail.com \
--cc=jltobler@gmail.com \
--cc=ps@pks.im \
--cc=rjusto@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).