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

From: Patrick Steinhardt <[email-masked]>
Date: Tue, 2 Jun 2026 14:34:45 +0200

On Tue, Jun 02, 2026 at 05:27:41PM +0900, Junio C Hamano wrote:
> Patrick Steinhardt <[email-masked]> writes:
> 
> > I wouldn't mind that outcome much, either. What triggered this series is
> > that I'm always annoyed that it's "builtin/init-db.c" instead of
> > "builtin/init.c", and the same for `cmd_init_db()`. But I intentionally
> > constructed the series in a way that the first commit can be picked
> > as-is, so that we can adjust our code to the modern world while not
> > doing the deprecation dance.
> >
> > So I'd be equally happy if we just drop the second commit in this
> > series.
> 
> I'd actually find myself annoyed by such a rename when looking for
> builtin/init-db.c only to find it gone---much like how a previous
> rename made ll-merge difficult to locate.
> 
> My point is that while static names may annoy some, renaming them
> does not resolve the annoyance; it merely shifts it to someone else.
> 
> So, if the primary motivation is just the first patch, I would be
> less inclined to support this series.

That's entirely fair. My take on this is a bit different, as I think
it's beneficial to accept a short-term adjustment for core contributors
in favor of making stuff easier to discover/maintain going forward.

A new contributor would probably be quick to learn that every
`cmd_foo()` entry point is named exactly the same as the subcommand
name, but they will then eventually trip over the few exceptions like
`cmd_init_db()` where that assumption doesn't hold.

But I can see that this is not always clear-cut.

Patrick