[PATCH 0/2] Deprecate git-init-db(1) alias

[PATCH 0/2] Deprecate git-init-db(1) alias

[Patrick Steinhardt]

Hi,

this small patch series deprecates the git-init-db(1) alias in favor of
git-init(1).

Patrick

---
Patrick Steinhardt (2):
      builtin/init-db: rename to "builtin/init.c"
      builtin/init-db: deprecate alias for git-init(1)

 Documentation/BreakingChanges.adoc | 3 +++
 Documentation/Makefile             | 1 +
 Documentation/git-init-db.adoc     | 5 +++++
 Documentation/meson.build          | 2 +-
 Makefile                           | 4 ++--
 builtin.h                          | 2 +-
 builtin/{init-db.c => init.c}      | 8 ++++----
 git.c                              | 6 ++++--
 meson.build                        | 2 +-
 t/t5502-quickfetch.sh              | 4 ++--
 t/t5503-tagfollow.sh               | 2 +-
 11 files changed, 25 insertions(+), 14 deletions(-)


---
base-commit: 1666c1265231b0bc5f613fbbf3f0a9896cdef76e
change-id: 20260601-pks-deprecate-git-init-db-c0e8d7f8b94e

[PATCH 1/2] builtin/init-db: rename to "builtin/init.c"

[Patrick Steinhardt]

Rename "builtin/init-db.c" to "builtin/init.c" to match the modern
git-init(1) command name instead of its ancient alias git-init-db(1).

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Makefile                      | 4 ++--
 builtin.h                     | 2 +-
 builtin/{init-db.c => init.c} | 8 ++++----
 git.c                         | 4 ++--
 meson.build                   | 2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index b31ecb0756..b03f74ee8c 100644
--- a/Makefile
+++ b/Makefile
@@ -894,7 +894,7 @@ BUILT_INS += git-cherry-pick$X
 BUILT_INS += git-format-patch$X
 BUILT_INS += git-format-rev$X
 BUILT_INS += git-fsck-objects$X
-BUILT_INS += git-init$X
+BUILT_INS += git-init-db$X
 BUILT_INS += git-maintenance$X
 BUILT_INS += git-merge-subtree$X
 BUILT_INS += git-restore$X
@@ -1428,7 +1428,7 @@ BUILTIN_OBJS += builtin/help.o
 BUILTIN_OBJS += builtin/history.o
 BUILTIN_OBJS += builtin/hook.o
 BUILTIN_OBJS += builtin/index-pack.o
-BUILTIN_OBJS += builtin/init-db.o
+BUILTIN_OBJS += builtin/init.o
 BUILTIN_OBJS += builtin/interpret-trailers.o
 BUILTIN_OBJS += builtin/last-modified.o
 BUILTIN_OBJS += builtin/log.o
diff --git a/builtin.h b/builtin.h
index 4e47a4ebd3..bd072aa0e4 100644
--- a/builtin.h
+++ b/builtin.h
@@ -200,7 +200,7 @@ int cmd_help(int argc, const char **argv, const char *prefix, struct repository
 int cmd_history(int argc, const char **argv, const char *prefix, struct repository *repo);
 int cmd_hook(int argc, const char **argv, const char *prefix, struct repository *repo);
 int cmd_index_pack(int argc, const char **argv, const char *prefix, struct repository *repo);
-int cmd_init_db(int argc, const char **argv, const char *prefix, struct repository *repo);
+int cmd_init(int argc, const char **argv, const char *prefix, struct repository *repo);
 int cmd_interpret_trailers(int argc, const char **argv, const char *prefix, struct repository *repo);
 int cmd_last_modified(int argc, const char **argv, const char *prefix, struct repository *repo);
 int cmd_log_reflog(int argc, const char **argv, const char *prefix, struct repository *repo);
diff --git a/builtin/init-db.c b/builtin/init.c
similarity index 98%
rename from builtin/init-db.c
rename to builtin/init.c
index c55517ad94..9184f2fc2c 100644
--- a/builtin/init-db.c
+++ b/builtin/init.c
@@ -69,10 +69,10 @@ static const char *const init_db_usage[] = {
  * On the other hand, it might just make lookup slower and messier. You
  * be the judge.  The default case is to have one DB per managed directory.
  */
-int cmd_init_db(int argc,
-		const char **argv,
-		const char *prefix,
-		struct repository *repo UNUSED)
+int cmd_init(int argc,
+	     const char **argv,
+	     const char *prefix,
+	     struct repository *repo UNUSED)
 {
 	char *git_dir;
 	const char *real_git_dir = NULL;
diff --git a/git.c b/git.c
index 36f08891ef..a72394b599 100644
--- a/git.c
+++ b/git.c
@@ -590,8 +590,8 @@ static struct cmd_struct commands[] = {
 	{ "history", cmd_history, RUN_SETUP },
 	{ "hook", cmd_hook, RUN_SETUP_GENTLY },
 	{ "index-pack", cmd_index_pack, RUN_SETUP_GENTLY | NO_PARSEOPT },
-	{ "init", cmd_init_db },
-	{ "init-db", cmd_init_db },
+	{ "init", cmd_init },
+	{ "init-db", cmd_init },
 	{ "interpret-trailers", cmd_interpret_trailers, RUN_SETUP_GENTLY },
 	{ "last-modified", cmd_last_modified, RUN_SETUP },
 	{ "log", cmd_log, RUN_SETUP },
diff --git a/meson.build b/meson.build
index 064fe2e2f1..682e46e7eb 100644
--- a/meson.build
+++ b/meson.build
@@ -634,7 +634,7 @@ builtin_sources = [
   'builtin/history.c',
   'builtin/hook.c',
   'builtin/index-pack.c',
-  'builtin/init-db.c',
+  'builtin/init.c',
   'builtin/interpret-trailers.c',
   'builtin/last-modified.c',
   'builtin/log.c',

-- 
2.54.0.926.g75ba10bac6.dirty

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

[Patrick Steinhardt]

The git-init-db(1) command was initially only initializing the object
database of a Git repository. This has changed over time so that the
command also initializes all the other data structures, which is why we
have eventually introduced git-init(1) as a more aptly named replacement
for it.

This has all happened in 2007 already, and with 5c94f87e6b (use 'init'
instead of 'init-db' for shipped docs and tools, 2007-01-12) we have
also adapted all user-facing documentation to mention the replacement.
It is thus safe to assume that (almost) nobody uses git-init-db(1)
nowadays anymore.

Deprecate the command in favor of git-init(1) and wire up the removal
when compiling Git with breaking changes enabled.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 Documentation/BreakingChanges.adoc | 3 +++
 Documentation/Makefile             | 1 +
 Documentation/git-init-db.adoc     | 5 +++++
 Documentation/meson.build          | 2 +-
 Makefile                           | 2 +-
 git.c                              | 2 ++
 t/t5502-quickfetch.sh              | 4 ++--
 t/t5503-tagfollow.sh               | 2 +-
 8 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index 73bb939359..89b7482f54 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -300,6 +300,9 @@ references.
 +
 These features will be removed.
 
+* The git-init-db(1) command is an alias for its modern drop-in replacement
+  git-init(1). The alias will be removed.
+
 * Support for "--stdin" option in the "name-rev" command was
   deprecated (and hidden from the documentation) in the Git 2.40
   timeframe, in preference to its synonym "--annotate-stdin".  Git 3.0
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 2699f0b24a..3769856b58 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -541,6 +541,7 @@ lint-docs-meson:
 		sort >tmp-meson-diff/meson.adoc && \
 	ls git*.adoc scalar.adoc | \
 		grep -v -e git-bisect-lk2009.adoc \
+			-e git-init-db.adoc \
 			-e git-pack-redundant.adoc \
 			-e git-tools.adoc \
 			-e git-whatchanged.adoc \
diff --git a/Documentation/git-init-db.adoc b/Documentation/git-init-db.adoc
index 18bf1a3c8c..9802fc9f3d 100644
--- a/Documentation/git-init-db.adoc
+++ b/Documentation/git-init-db.adoc
@@ -11,6 +11,11 @@ SYNOPSIS
 [verse]
 'git init-db' [-q | --quiet] [--bare] [--template=<template-directory>] [--separate-git-dir <git-dir>] [--shared[=<permissions>]]
 
+WARNING
+-------
+
+`git init-db` has been deprecated in favor of `git init`, which is a drop-in
+replacement for `git init-db`.
 
 DESCRIPTION
 -----------
diff --git a/Documentation/meson.build b/Documentation/meson.build
index f4854f802d..0f127d752d 100644
--- a/Documentation/meson.build
+++ b/Documentation/meson.build
@@ -72,7 +72,6 @@ manpages = {
   'git-http-push.adoc' : 1,
   'git-imap-send.adoc' : 1,
   'git-index-pack.adoc' : 1,
-  'git-init-db.adoc' : 1,
   'git-init.adoc' : 1,
   'git-instaweb.adoc' : 1,
   'git-interpret-trailers.adoc' : 1,
@@ -212,6 +211,7 @@ manpages = {
 }
 
 manpages_breaking_changes = {
+  'git-init-db.adoc' : 1,
   'git-pack-redundant.adoc' : 1,
   'git-whatchanged.adoc' : 1,
 }
diff --git a/Makefile b/Makefile
index b03f74ee8c..4420231753 100644
--- a/Makefile
+++ b/Makefile
@@ -894,7 +894,6 @@ BUILT_INS += git-cherry-pick$X
 BUILT_INS += git-format-patch$X
 BUILT_INS += git-format-rev$X
 BUILT_INS += git-fsck-objects$X
-BUILT_INS += git-init-db$X
 BUILT_INS += git-maintenance$X
 BUILT_INS += git-merge-subtree$X
 BUILT_INS += git-restore$X
@@ -904,6 +903,7 @@ BUILT_INS += git-status$X
 BUILT_INS += git-switch$X
 BUILT_INS += git-version$X
 ifndef WITH_BREAKING_CHANGES
+BUILT_INS += git-init-db$X
 BUILT_INS += git-whatchanged$X
 endif
 
diff --git a/git.c b/git.c
index a72394b599..6bf6a60360 100644
--- a/git.c
+++ b/git.c
@@ -591,7 +591,9 @@ static struct cmd_struct commands[] = {
 	{ "hook", cmd_hook, RUN_SETUP_GENTLY },
 	{ "index-pack", cmd_index_pack, RUN_SETUP_GENTLY | NO_PARSEOPT },
 	{ "init", cmd_init },
+#ifndef WITH_BREAKING_CHANGES
 	{ "init-db", cmd_init },
+#endif
 	{ "interpret-trailers", cmd_interpret_trailers, RUN_SETUP_GENTLY },
 	{ "last-modified", cmd_last_modified, RUN_SETUP },
 	{ "log", cmd_log, RUN_SETUP },
diff --git a/t/t5502-quickfetch.sh b/t/t5502-quickfetch.sh
index b160f8b7fb..a2b62f551a 100755
--- a/t/t5502-quickfetch.sh
+++ b/t/t5502-quickfetch.sh
@@ -25,7 +25,7 @@ test_expect_success 'clone without alternate' '
 	(
 		mkdir cloned &&
 		cd cloned &&
-		git init-db &&
+		git init &&
 		git remote add -f origin ..
 	) &&
 	cnt=$( (
@@ -94,7 +94,7 @@ test_expect_success 'quickfetch should not copy from alternate' '
 	(
 		mkdir quickclone &&
 		cd quickclone &&
-		git init-db &&
+		git init &&
 		(cd ../.git/objects && pwd) >.git/objects/info/alternates &&
 		git remote add origin .. &&
 		git fetch -k -k
diff --git a/t/t5503-tagfollow.sh b/t/t5503-tagfollow.sh
index febe441041..31ec352c5c 100755
--- a/t/t5503-tagfollow.sh
+++ b/t/t5503-tagfollow.sh
@@ -32,7 +32,7 @@ test_expect_success setup '
 	(
 		mkdir cloned &&
 		cd cloned &&
-		git init-db &&
+		git init &&
 		git remote add -f origin ..
 	) &&
 

-- 
2.54.0.926.g75ba10bac6.dirty

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

[Kristoffer Haugsbakk]

On Mon, Jun 1, 2026, at 09:56, Patrick Steinhardt wrote:
> The git-init-db(1) command was initially only initializing the object
> database of a Git repository. This has changed over time so that the
> command also initializes all the other data structures, which is why we
> have eventually introduced git-init(1) as a more aptly named replacement
> for it.
>
> This has all happened in 2007 already, and with 5c94f87e6b (use 'init'
> instead of 'init-db' for shipped docs and tools, 2007-01-12) we have
> also adapted all user-facing documentation to mention the replacement.
> It is thus safe to assume that (almost) nobody uses git-init-db(1)
> nowadays anymore.
>
> Deprecate the command in favor of git-init(1) and wire up the removal
> when compiling Git with breaking changes enabled.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>[snip]
> diff --git a/git.c b/git.c
> index a72394b599..6bf6a60360 100644
> --- a/git.c
> +++ b/git.c
> @@ -591,7 +591,9 @@ static struct cmd_struct commands[] = {
>  	{ "hook", cmd_hook, RUN_SETUP_GENTLY },
>  	{ "index-pack", cmd_index_pack, RUN_SETUP_GENTLY | NO_PARSEOPT },
>  	{ "init", cmd_init },
> +#ifndef WITH_BREAKING_CHANGES
>  	{ "init-db", cmd_init },

This can be marked as deprecated.

	{ "init-db", cmd_init, DEPRECATED },

> +#endif
>  	{ "interpret-trailers", cmd_interpret_trailers, RUN_SETUP_GENTLY },
>  	{ "last-modified", cmd_last_modified, RUN_SETUP },
>  	{ "log", cmd_log, RUN_SETUP },
>[snip]

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

[Patrick Steinhardt]

On Mon, Jun 01, 2026 at 11:31:46AM +0200, Kristoffer Haugsbakk wrote:
> On Mon, Jun 1, 2026, at 09:56, Patrick Steinhardt wrote:
> > diff --git a/git.c b/git.c
> > index a72394b599..6bf6a60360 100644
> > --- a/git.c
> > +++ b/git.c
> > @@ -591,7 +591,9 @@ static struct cmd_struct commands[] = {
> >  	{ "hook", cmd_hook, RUN_SETUP_GENTLY },
> >  	{ "index-pack", cmd_index_pack, RUN_SETUP_GENTLY | NO_PARSEOPT },
> >  	{ "init", cmd_init },
> > +#ifndef WITH_BREAKING_CHANGES
> >  	{ "init-db", cmd_init },
> 
> This can be marked as deprecated.
> 
> 	{ "init-db", cmd_init, DEPRECATED },

Ah, indeed! Added locally now, thanks.

Patrick

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

[Phillip Wood]

On 01/06/2026 13:10, Patrick Steinhardt wrote:
> On Mon, Jun 01, 2026 at 11:31:46AM +0200, Kristoffer Haugsbakk wrote:
>> On Mon, Jun 1, 2026, at 09:56, Patrick Steinhardt wrote:
>>> diff --git a/git.c b/git.c
>>> index a72394b599..6bf6a60360 100644
>>> --- a/git.c
>>> +++ b/git.c
>>> @@ -591,7 +591,9 @@ static struct cmd_struct commands[] = {
>>>   	{ "hook", cmd_hook, RUN_SETUP_GENTLY },
>>>   	{ "index-pack", cmd_index_pack, RUN_SETUP_GENTLY | NO_PARSEOPT },
>>>   	{ "init", cmd_init },
>>> +#ifndef WITH_BREAKING_CHANGES
>>>   	{ "init-db", cmd_init },
>>
>> This can be marked as deprecated.
>>
>> 	{ "init-db", cmd_init, DEPRECATED },
> 
> Ah, indeed! Added locally now, thanks.

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.

Thanks

Phillip

> Patrick
> 

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

[Patrick Steinhardt]

On Mon, Jun 01, 2026 at 02:48:05PM +0100, Phillip Wood wrote:
> 
> 
> On 01/06/2026 13:10, Patrick Steinhardt wrote:
> > On Mon, Jun 01, 2026 at 11:31:46AM +0200, Kristoffer Haugsbakk wrote:
> > > On Mon, Jun 1, 2026, at 09:56, Patrick Steinhardt wrote:
> > > > diff --git a/git.c b/git.c
> > > > index a72394b599..6bf6a60360 100644
> > > > --- a/git.c
> > > > +++ b/git.c
> > > > @@ -591,7 +591,9 @@ static struct cmd_struct commands[] = {
> > > >   	{ "hook", cmd_hook, RUN_SETUP_GENTLY },
> > > >   	{ "index-pack", cmd_index_pack, RUN_SETUP_GENTLY | NO_PARSEOPT },
> > > >   	{ "init", cmd_init },
> > > > +#ifndef WITH_BREAKING_CHANGES
> > > >   	{ "init-db", cmd_init },
> > > 
> > > This can be marked as deprecated.
> > > 
> > > 	{ "init-db", cmd_init, DEPRECATED },
> > 
> > Ah, indeed! Added locally now, thanks.
> 
> 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. 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.

Patrick

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

[Kristoffer Haugsbakk]

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/d8c1df4e-a4d7-4c4c-be44-b13de3d9ffea@markus-raab.org/

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. ;)

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

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Mon, Jun 01, 2026 at 02:48:05PM +0100, Phillip Wood wrote:
>> 
>> 
>> On 01/06/2026 13:10, Patrick Steinhardt wrote:
>> > On Mon, Jun 01, 2026 at 11:31:46AM +0200, Kristoffer Haugsbakk wrote:
>> > > On Mon, Jun 1, 2026, at 09:56, Patrick Steinhardt wrote:
>> > > > diff --git a/git.c b/git.c
>> > > > index a72394b599..6bf6a60360 100644
>> > > > --- a/git.c
>> > > > +++ b/git.c
>> > > > @@ -591,7 +591,9 @@ static struct cmd_struct commands[] = {
>> > > >   	{ "hook", cmd_hook, RUN_SETUP_GENTLY },
>> > > >   	{ "index-pack", cmd_index_pack, RUN_SETUP_GENTLY | NO_PARSEOPT },
>> > > >   	{ "init", cmd_init },
>> > > > +#ifndef WITH_BREAKING_CHANGES
>> > > >   	{ "init-db", cmd_init },
>> > > 
>> > > This can be marked as deprecated.
>> > > 
>> > > 	{ "init-db", cmd_init, DEPRECATED },
>> > 
>> > Ah, indeed! Added locally now, thanks.
>> 
>> 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. 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 personally think you_still_use_that() was a mistake.  Perhaps
log-family of commands were used often enough to warrant it, but not
"init" that takes exactly the same variations of arguments and is
shorter than "init-db".  And you_still_use_that() would not help
scripted use all that much.

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

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

>> 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. ;)

Or just leave it without deprecation.  It does not cost much to keep
"init-db", and because we expanded what "git database" means in
later versions of Git since its invention, the name still makes
sense.  Thank Linus for not naming it "init-odb"---that might have
been a valid excuse to rename it because it does not cover the ref
database and config database and others.

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

[Patrick Steinhardt]

On Tue, Jun 02, 2026 at 07:22:50AM +0900, Junio C Hamano wrote:
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> 
> >> 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. ;)
> 
> Or just leave it without deprecation.  It does not cost much to keep
> "init-db", and because we expanded what "git database" means in
> later versions of Git since its invention, the name still makes
> sense.  Thank Linus for not naming it "init-odb"---that might have
> been a valid excuse to rename it because it does not cover the ref
> database and config database and others.

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.

Patrick

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

[Kristoffer Haugsbakk]

On Tue, Jun 2, 2026, at 08:45, Patrick Steinhardt wrote:
> On Tue, Jun 02, 2026 at 07:22:50AM +0900, Junio C Hamano wrote:
>> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>>>[snip]
>> Or just leave it without deprecation.  It does not cost much to keep
>> "init-db", and because we expanded what "git database" means in
>> later versions of Git since its invention, the name still makes
>> sense.  Thank Linus for not naming it "init-odb"---that might have
>> been a valid excuse to rename it because it does not cover the ref
>> database and config database and others.
>
> 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.

Could it be worthwhile to mark it as soft deprecated? In the sense that
it is a legacy alias that is not planned for removal?

What I think was mistake in topic jc/you-still-use-whatchanged was that
git-whatchanged(1) was not explicitly marked as deprecated before that
series, and then it started failing without a new `--i-still-use-this`
flag. The doc before that said:

    New users are encouraged to use git-log(1) instead.  The
    `whatchanged` command is essentially the same as git-log(1) but
    defaults to showing the raw format diff output and skipping merges.

    The command is primarily kept for historical reasons; fingers of
    many people who learned Git long before `git log` was invented by
    reading the Linux kernel mailing list are trained to type it.

Reading between the lines, this looks like a soft deprecation. Then
there were emails that said that there was no prior warning. And then
someone replied to that saying that it had really been deprecated for
over a decade because that was the intent.[1] But IMO just saying
something to the effect of soft deprecated would have been better
(before it got hard deprecated).

Trying to simulate amnesia, I think just the word “init-db” looks
slightly legacy, and the fact that the documentation just links to
git-init(1) solidifies that. On the other hand git-stage(1) was
introduced as a better name for “staging” files and that too just links
to git-add(1). So you have two commands which just link to other
commands, but one is definitely more deprecated than the other.

† 1: But “trained fingers” reading the man page every other year on the
     off chance that there are new developments? That’s another
     question.

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

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> 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.

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

[Patrick Steinhardt]

On Tue, Jun 02, 2026 at 09:54:02AM +0200, Kristoffer Haugsbakk wrote:
> On Tue, Jun 2, 2026, at 08:45, Patrick Steinhardt wrote:
> > On Tue, Jun 02, 2026 at 07:22:50AM +0900, Junio C Hamano wrote:
> >> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> >>>[snip]
> >> Or just leave it without deprecation.  It does not cost much to keep
> >> "init-db", and because we expanded what "git database" means in
> >> later versions of Git since its invention, the name still makes
> >> sense.  Thank Linus for not naming it "init-odb"---that might have
> >> been a valid excuse to rename it because it does not cover the ref
> >> database and config database and others.
> >
> > 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.
> 
> Could it be worthwhile to mark it as soft deprecated? In the sense that
> it is a legacy alias that is not planned for removal?

The question is how such a soft deprecation would look like. Would it be
a warning, only, but other than that it behaves just as before? Should
we mark it as `DEPRECATED` in "git.c"? Both of those?

Patrick

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

[Patrick Steinhardt]

On Tue, Jun 02, 2026 at 05:27:41PM +0900, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> 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

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

[Phillip Wood]

Hi Patrick

On 01/06/2026 15:20, Patrick Steinhardt wrote:
> On Mon, Jun 01, 2026 at 02:48:05PM +0100, Phillip Wood wrote:
>>
>>
>> On 01/06/2026 13:10, Patrick Steinhardt wrote:
>>> On Mon, Jun 01, 2026 at 11:31:46AM +0200, Kristoffer Haugsbakk wrote:
>>>> On Mon, Jun 1, 2026, at 09:56, Patrick Steinhardt wrote:
>>>>> diff --git a/git.c b/git.c
>>>>> index a72394b599..6bf6a60360 100644
>>>>> --- a/git.c
>>>>> +++ b/git.c
>>>>> @@ -591,7 +591,9 @@ static struct cmd_struct commands[] = {
>>>>>    	{ "hook", cmd_hook, RUN_SETUP_GENTLY },
>>>>>    	{ "index-pack", cmd_index_pack, RUN_SETUP_GENTLY | NO_PARSEOPT },
>>>>>    	{ "init", cmd_init },
>>>>> +#ifndef WITH_BREAKING_CHANGES
>>>>>    	{ "init-db", cmd_init },
>>>>
>>>> This can be marked as deprecated.
>>>>
>>>> 	{ "init-db", cmd_init, DEPRECATED },
>>>
>>> Ah, indeed! Added locally now, thanks.
>>
>> 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. 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().

Thanks

Phillip

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

[Phillip Wood]

On 02/06/2026 13:34, Patrick Steinhardt wrote:
> 
> 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.

Yes, those exceptions to the rule are annoying. Though they mostly exist 
for a good reason (code sharing between builtin commands), it would be 
nice to minimize them where we can.

Thanks

Phillip

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

[Junio C Hamano]

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().

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

[Patrick Steinhardt]

On Tue, Jun 02, 2026 at 02:12:58PM +0100, Phillip Wood wrote:
> On 02/06/2026 13:34, Patrick Steinhardt wrote:
> > 
> > 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.
> 
> Yes, those exceptions to the rule are annoying. Though they mostly exist for
> a good reason (code sharing between builtin commands), it would be nice to
> minimize them where we can.

Either minimize, or if we don't want to (or can't) the next best thing
is to pick the variant that most folks will know about. Which would be
the case if we just picked the first patch in this series.

Patrick

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

[SZEDER Gábor]

On Tue, Jun 02, 2026 at 02:34:45PM +0200, Patrick Steinhardt wrote:
> On Tue, Jun 02, 2026 at 05:27:41PM +0900, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> 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.

That's not a short-term adjustment, but it will be an ongoing
annoyance, because 'git log builtin/init.c' will cut off at the rename
barrier.