Subject: Re: [PATCH 2/2] builtin/init-db: deprecate alias for git-init(1)

From: "Kristoffer Haugsbakk" <[email-masked]>
Date: Mon, 01 Jun 2026 23:23:44 +0200

By the way I tried to find user mentions of git-init-db(1) on the
mailing list. (First git then I tried *all* but the results did not seem
dissimilar at all.) All I found was from last year[1] but the command
was used as a bug reproducer, which hints at some finger memory.

🔗 1: https://lore.kernel.org/git/[email-masked]/

On Mon, Jun 1, 2026, at 16:20, Patrick Steinhardt wrote:
> On Mon, Jun 01, 2026 at 02:48:05PM +0100, Phillip Wood wrote:
>>[snip
>>
>> Deprecating this command seems very sensible to me. As well as marking it
>> deprecated, do we want to print a warning when it is run? I imagine anyone
>> who has this command in their muscle memory is unlikely to be reading the
>> man page on a regular basis so wont see the warning there.
>
> I was wondering whether we want to call `you_still_use_that()` here.

As-is that will arguably promote the *breaking change* to right now
since it’s a `die(...)` function. That could be changed to be warn/die
modular of course.

But a simple warning message can just tell them to use git-init(1).

> 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 imagine that most potential git-init-db(1) uses will be buried in some
scripts that haven’t been touched in years. Then the Git init might
fail, you get errors about git-commit(1) or something not being a thing
you can run without a repository, and it ends up being a headscratcher
since the original failure gets lost.

All to say I think a simple warning would be nice. ;)