Volume XXII, number 280Wednesday, October 7, 2026Latest message 54 minutes ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

patch, 2 partsDeprecate git-init-db(1) alias

20 messages between Jun 1, 2026 and Jun 2, 2026, from Patrick Steinhardt, Kristoffer Haugsbakk, Phillip Wood, Junio C Hamano, SZEDER Gábor.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

Patrick SteinhardtJun 1, 2026, 07:55 UTC on lore
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

Patrick SteinhardtJun 1, 2026, 07:55 UTC in reply to Patrick Steinhardt on lore

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

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(-)
Show changes to 6 files +10 −10

Makefile, builtin.h, builtin/init-db.c, builtin/init.c, git.c, meson.build

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
Patrick SteinhardtJun 1, 2026, 07:56 UTC in reply to Patrick Steinhardt on lore

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

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(-)
Show changes to 8 files +16 −5

Documentation/BreakingChanges.adoc, Documentation/Makefile, Documentation/git-init-db.adoc, Documentation/meson.build, Makefile, git.c, t/t5502-quickfetch.sh, t/t5503-tagfollow.sh

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
Kristoffer HaugsbakkJun 1, 2026, 09:31 UTC in reply to Patrick Steinhardt on lore

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

On Mon, Jun 1, 2026, at 09:56, Patrick Steinhardt wrote:
Show 28 quoted lines
> 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 },
Show 5 quoted lines
> +#endif
>  	{ "interpret-trailers", cmd_interpret_trailers, RUN_SETUP_GENTLY },
>  	{ "last-modified", cmd_last_modified, RUN_SETUP },
>  	{ "log", cmd_log, RUN_SETUP },
>[snip]
Patrick SteinhardtJun 1, 2026, 12:10 UTC in reply to Kristoffer Haugsbakk on lore

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

On Mon, Jun 01, 2026 at 11:31:46AM +0200, Kristoffer Haugsbakk wrote:
Show 15 quoted lines
> 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
Phillip WoodJun 1, 2026, 13:48 UTC in reply to Patrick Steinhardt on lore

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

On 01/06/2026 13:10, Patrick Steinhardt wrote:
Show 18 quoted lines
> 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
> 
Patrick SteinhardtJun 1, 2026, 14:20 UTC in reply to Phillip Wood on lore

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

On Mon, Jun 01, 2026 at 02:48:05PM +0100, Phillip Wood wrote:
Show 26 quoted lines
> 
> 
> 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
Kristoffer HaugsbakkJun 1, 2026, 21:23 UTC in reply to Patrick Steinhardt on lore

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

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:
Show 9 quoted lines
> 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. ;)
Junio C HamanoJun 1, 2026, 22:18 UTC in reply to Patrick Steinhardt on lore

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

Patrick Steinhardt <ps@pks.im> writes:
Show 31 quoted lines
> 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.

Junio C HamanoJun 1, 2026, 22:22 UTC in reply to Kristoffer Haugsbakk on lore

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

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
Show 10 quoted lines
>> 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.

Patrick SteinhardtJun 2, 2026, 06:45 UTC in reply to Junio C Hamano on lore

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

On Tue, Jun 02, 2026 at 07:22:50AM +0900, Junio C Hamano wrote:
Show 19 quoted lines
> "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
Kristoffer HaugsbakkJun 2, 2026, 07:54 UTC in reply to Patrick Steinhardt on lore

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

On Tue, Jun 2, 2026, at 08:45, Patrick Steinhardt wrote:
Show 19 quoted lines
> 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.
Junio C HamanoJun 2, 2026, 08:27 UTC in reply to Patrick Steinhardt on lore

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

Patrick Steinhardt <ps@pks.im> writes:
Show 9 quoted lines
> 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.

Patrick SteinhardtJun 2, 2026, 12:34 UTC in reply to Kristoffer Haugsbakk on lore

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

On Tue, Jun 02, 2026 at 09:54:02AM +0200, Kristoffer Haugsbakk wrote:
Show 23 quoted lines
> 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
Patrick SteinhardtJun 2, 2026, 12:34 UTC in reply to Junio C Hamano on lore

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

On Tue, Jun 02, 2026 at 05:27:41PM +0900, Junio C Hamano wrote:
Show 21 quoted lines
> 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
Phillip WoodJun 2, 2026, 13:09 UTC in reply to Patrick Steinhardt on lore

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

Hi Patrick
On 01/06/2026 15:20, Patrick Steinhardt wrote:
Show 31 quoted lines
> 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
Phillip WoodJun 2, 2026, 13:12 UTC in reply to Patrick Steinhardt on lore

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

On 02/06/2026 13:34, Patrick Steinhardt wrote:
Show 8 quoted lines
> 
> 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
Junio C HamanoJun 2, 2026, 13:50 UTC in reply to Phillip Wood on lore

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

Phillip Wood <phillip.wood123@gmail.com> writes:
Show 12 quoted lines
>> 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().

Patrick SteinhardtJun 2, 2026, 14:58 UTC in reply to Phillip Wood on lore

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

On Tue, Jun 02, 2026 at 02:12:58PM +0100, Phillip Wood wrote:
Show 13 quoted lines
> 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
SZEDER GáborJun 2, 2026, 15:24 UTC in reply to Patrick Steinhardt on lore

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

On Tue, Jun 02, 2026 at 02:34:45PM +0200, Patrick Steinhardt wrote:
Show 26 quoted lines
> 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.

Back to recent threads