From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Patrick Steinhardt <ps@pks.im>,
phillip.wood@dunelm.org.uk,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 2/2] builtin/init-db: deprecate alias for git-init(1)
Date: Tue, 02 Jun 2026 22:50:03 +0900 [thread overview]
Message-ID: <xmqq5x41vypg.fsf@gitster.g> (raw)
In-Reply-To: <336a4202-a55f-4223-b654-985d47233653@gmail.com> (Phillip Wood's message of "Tue, 2 Jun 2026 14:09:39 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
>> I was wondering whether we want to call `you_still_use_that()` here. I
>> found it to be a bit heavy-handed as it's so trivial to replace with
>> git-init(1), but on the other hand it's a trivial thing to do.
>
> I agree you_still_use_that() is too heavy handed, I was thinking of
> something like
>
> warning(_("this command is deprecated, please use \"git init\""
> "instead");
>
> but that would mean we need to add a separate cmd_init_db() function
> that prints the warning and then calls cmd_init().
If we do plan to remove it in the future, then something like that
may be needed.
But it is not like having "init-db" hidden but accessible in the
command table is hurting anything. Other than that those who want
to create their own
[alias "init-db"] command = foo
that is, and I'd see it a bit crazy.
The "init-db" form is hidden from "git help" listing, and we know
whenever we suggest to run "git init" we do not say "git init-db",
so if we do not have to remove it in the future, I do not think we
even need such a warning().
prev parent reply other threads:[~2026-06-02 13:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 7:55 [PATCH 0/2] Deprecate git-init-db(1) alias Patrick Steinhardt
2026-06-01 7:55 ` [PATCH 1/2] builtin/init-db: rename to "builtin/init.c" Patrick Steinhardt
2026-06-01 7:56 ` [PATCH 2/2] builtin/init-db: deprecate alias for git-init(1) Patrick Steinhardt
2026-06-01 9:31 ` Kristoffer Haugsbakk
2026-06-01 12:10 ` Patrick Steinhardt
2026-06-01 13:48 ` Phillip Wood
2026-06-01 14:20 ` Patrick Steinhardt
2026-06-01 21:23 ` Kristoffer Haugsbakk
2026-06-01 22:22 ` Junio C Hamano
2026-06-02 6:45 ` Patrick Steinhardt
2026-06-02 7:54 ` Kristoffer Haugsbakk
2026-06-02 12:34 ` Patrick Steinhardt
2026-06-02 8:27 ` Junio C Hamano
2026-06-02 12:34 ` Patrick Steinhardt
2026-06-02 13:12 ` Phillip Wood
2026-06-02 14:58 ` Patrick Steinhardt
2026-06-02 15:24 ` SZEDER Gábor
2026-06-01 22:18 ` Junio C Hamano
2026-06-02 13:09 ` Phillip Wood
2026-06-02 13:50 ` 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=xmqq5x41vypg.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
/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