[PATCH 0/2] commit: remove deprecated functions

[PATCH 0/2] commit: remove deprecated functions

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

Topic name: kh/commit-deprecated

Topic summary: Remove deprecated comments that were slated for removal
after Git 2.53.0.

See the comment:

    /*
     * Deprecated compatibility functions for `struct commit_list`, to be removed
     * once Git 2.53 is released.
     */

I merged in `seen` and `next` yesterday and found no new in-flight usages
of these functions.

I commented on this patch but apparently it hasn’t hit any of these
integration branches yet:

Patch: replay: support replaying 2-parent merges
Link: https://lore.kernel.org/git/920cc022-8b63-4dbb-a41d-957ee01a5efd@app.fastmail.com/

[1/2] *: replace deprecated free_commit_list
[2/2] commit: remove deprecated functions

 builtin/history.c |  4 ++--
 commit.h          | 19 -------------------
 replay.c          |  2 +-
 upload-pack.c     |  4 ++--
 4 files changed, 5 insertions(+), 24 deletions(-)


base-commit: 56a4f3c3a221adf1df9b39da69b8a6890f803157
-- 
2.54.0.6.gf6fa7dd4140

[PATCH 1/2] *: replace deprecated free_commit_list

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

Replace `free_commit_list` with `commit_list_free`. The former was
deprecated in 9f18d089 (commit: rename `free_commit_list()` to conform
to coding guidelines, 2026-01-15).

This allows us to remove all the deprecated functions in the
next commit:

• `copy_commit_list`
• `reverse_commit_list`
• `free_commit_list`

Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
 builtin/history.c | 4 ++--
 replay.c          | 2 +-
 upload-pack.c     | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/builtin/history.c b/builtin/history.c
index 0fc06fb2045..091465a59e2 100644
--- a/builtin/history.c
+++ b/builtin/history.c
@@ -284,7 +284,7 @@ static int setup_revwalk(struct repository *repo,
 
 		commit_list_insert(original, &from_list);
 		ret = repo_is_descendant_of(repo, head, from_list);
-		free_commit_list(from_list);
+		commit_list_free(from_list);
 
 		if (ret < 0) {
 			ret = error(_("cannot determine descendance"));
@@ -892,7 +892,7 @@ static int split_commit(struct repository *repo,
 	if (index_file.len)
 		unlink(index_file.buf);
 	strbuf_release(&index_file);
-	free_commit_list(parents);
+	commit_list_free(parents);
 	release_index(&index);
 	return ret;
 }
diff --git a/replay.c b/replay.c
index 4ef8abb6077..da531d5bc68 100644
--- a/replay.c
+++ b/replay.c
@@ -120,7 +120,7 @@ static struct commit *create_commit(struct repository *repo,
 out:
 	repo_unuse_commit_buffer(repo, based_on, message);
 	free_commit_extra_headers(extra);
-	free_commit_list(parents);
+	commit_list_free(parents);
 	strbuf_release(&msg);
 	free(author);
 	return (struct commit *)obj;
diff --git a/upload-pack.c b/upload-pack.c
index 9f6d6fe48c8..2bf450ab288 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -886,7 +886,7 @@ static void deepen(struct upload_pack_data *data, int depth)
 					     data->deepen_relative, depth,
 					     SHALLOW, NOT_SHALLOW);
 		send_shallow(data, result);
-		free_commit_list(result);
+		commit_list_free(result);
 	}
 
 	send_unshallow(data);
@@ -900,7 +900,7 @@ static void deepen_by_rev_list(struct upload_pack_data *data,
 	disable_commit_graph(the_repository);
 	result = get_shallow_commits_by_rev_list(argv, SHALLOW, NOT_SHALLOW);
 	send_shallow(data, result);
-	free_commit_list(result);
+	commit_list_free(result);
 	send_unshallow(data);
 }
 
-- 
2.54.0.6.gf6fa7dd4140

Re: [PATCH 1/2] *: replace deprecated free_commit_list

[Patrick Steinhardt]

On Wed, May 27, 2026 at 03:59:25PM +0200, kristofferhaugsbakk@fastmail.com wrote:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
> 
> Replace `free_commit_list` with `commit_list_free`. The former was
> deprecated in 9f18d089 (commit: rename `free_commit_list()` to conform
> to coding guidelines, 2026-01-15).
> 
> This allows us to remove all the deprecated functions in the
> next commit:
> 
> • `copy_commit_list`
> • `reverse_commit_list`
> • `free_commit_list`
> 
> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
> ---
>  builtin/history.c | 4 ++--
>  replay.c          | 2 +-
>  upload-pack.c     | 4 ++--
>  3 files changed, 5 insertions(+), 5 deletions(-)

Heh. Funny to see that I introduced the new functions, and that I was
also the one that continued using the old ones most :)

Patrick

Re: [PATCH 1/2] *: replace deprecated free_commit_list

[Kristoffer Haugsbakk]

On Thu, May 28, 2026, at 07:24, Patrick Steinhardt wrote:
> On Wed, May 27, 2026 at 03:59:25PM +0200,
>>[snip]
>> ---
>>  builtin/history.c | 4 ++--
>>  replay.c          | 2 +-
>>  upload-pack.c     | 4 ++--
>>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> Heh. Funny to see that I introduced the new functions, and that I was
> also the one that continued using the old ones most :)

To be honest with you that’s the first thing I checked. “I wonder if
Patrick...” x)

[PATCH 2/2] commit: remove deprecated functions

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

These functions were deprecated in a series of commits merged in
52882024 (Merge branch 'ps/commit-list-functions-renamed', 2026-02-13).

The compatibility was for in-flight topics at the time.

Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
 commit.h | 19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/commit.h b/commit.h
index 58150045afa..5352056f87a 100644
--- a/commit.h
+++ b/commit.h
@@ -203,25 +203,6 @@ struct commit_list *commit_list_reverse(struct commit_list *list);
 
 void commit_list_free(struct commit_list *list);
 
-/*
- * Deprecated compatibility functions for `struct commit_list`, to be removed
- * once Git 2.53 is released.
- */
-static inline struct commit_list *copy_commit_list(struct commit_list *l)
-{
-	return commit_list_copy(l);
-}
-
-static inline struct commit_list *reverse_commit_list(struct commit_list *l)
-{
-	return commit_list_reverse(l);
-}
-
-static inline void free_commit_list(struct commit_list *l)
-{
-	commit_list_free(l);
-}
-
 struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
 
 const char *repo_logmsg_reencode(struct repository *r,
-- 
2.54.0.6.gf6fa7dd4140

Re: [PATCH 2/2] commit: remove deprecated functions

[Patrick Steinhardt]

On Wed, May 27, 2026 at 03:59:26PM +0200, kristofferhaugsbakk@fastmail.com wrote:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
> 
> These functions were deprecated in a series of commits merged in
> 52882024 (Merge branch 'ps/commit-list-functions-renamed', 2026-02-13).
> 
> The compatibility was for in-flight topics at the time.

Yup, makes sense. Thanks for following through with the cleanup!

Patrick

[PATCH v2 0/2] commit: remove deprecated functions

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

Topic name: kh/commit-deprecated

Topic summary: Remove deprecated comments that were slated for removal
after Git 2.53.0.

See the comment:

    /*
     * Deprecated compatibility functions for `struct commit_list`, to be removed
     * once Git 2.53 is released.
     */

I merged in `seen` and `next` yesterday and found no new in-flight usages
of these functions.

Update Thursday: retested `seen` (commit [1]) and `next` (commit [2]).

† 1: 7821a69c (Merge branch 'za/completion-hide-dotfiles' into seen, 2026-05-27)
† 2: 2f8565e1 (Sync with 'master', 2026-05-27)

I commented on this patch but apparently it hasn’t hit any of these
integration branches yet:

Patch: replay: support replaying 2-parent merges
Link: https://lore.kernel.org/git/920cc022-8b63-4dbb-a41d-957ee01a5efd@app.fastmail.com/

§ Changes v2

Add ack by Patrick, the author of these compatibility functions.

§ Link to v1

https://lore.kernel.org/git/CV_commit.h_remove_deprecated.714@msgid.xyz/#t

[1/2] *: replace deprecated free_commit_list
[2/2] commit: remove deprecated functions

 builtin/history.c |  4 ++--
 commit.h          | 19 -------------------
 replay.c          |  2 +-
 upload-pack.c     |  4 ++--
 4 files changed, 5 insertions(+), 24 deletions(-)

Interdiff against v1:

base-commit: 56a4f3c3a221adf1df9b39da69b8a6890f803157
-- 
2.54.0.16.g8f27b399cbe

[PATCH v2 1/2] *: replace deprecated free_commit_list

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

Replace `free_commit_list` with `commit_list_free`. The former was
deprecated in 9f18d089 (commit: rename `free_commit_list()` to conform
to coding guidelines, 2026-01-15).

This allows us to remove all the deprecated functions in the
next commit:

• `copy_commit_list`
• `reverse_commit_list`
• `free_commit_list`

Acked-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---

Notes (series):
    v2: add ack

 builtin/history.c | 4 ++--
 replay.c          | 2 +-
 upload-pack.c     | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/builtin/history.c b/builtin/history.c
index 0fc06fb2045..091465a59e2 100644
--- a/builtin/history.c
+++ b/builtin/history.c
@@ -284,7 +284,7 @@ static int setup_revwalk(struct repository *repo,
 
 		commit_list_insert(original, &from_list);
 		ret = repo_is_descendant_of(repo, head, from_list);
-		free_commit_list(from_list);
+		commit_list_free(from_list);
 
 		if (ret < 0) {
 			ret = error(_("cannot determine descendance"));
@@ -892,7 +892,7 @@ static int split_commit(struct repository *repo,
 	if (index_file.len)
 		unlink(index_file.buf);
 	strbuf_release(&index_file);
-	free_commit_list(parents);
+	commit_list_free(parents);
 	release_index(&index);
 	return ret;
 }
diff --git a/replay.c b/replay.c
index 4ef8abb6077..da531d5bc68 100644
--- a/replay.c
+++ b/replay.c
@@ -120,7 +120,7 @@ static struct commit *create_commit(struct repository *repo,
 out:
 	repo_unuse_commit_buffer(repo, based_on, message);
 	free_commit_extra_headers(extra);
-	free_commit_list(parents);
+	commit_list_free(parents);
 	strbuf_release(&msg);
 	free(author);
 	return (struct commit *)obj;
diff --git a/upload-pack.c b/upload-pack.c
index 9f6d6fe48c8..2bf450ab288 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -886,7 +886,7 @@ static void deepen(struct upload_pack_data *data, int depth)
 					     data->deepen_relative, depth,
 					     SHALLOW, NOT_SHALLOW);
 		send_shallow(data, result);
-		free_commit_list(result);
+		commit_list_free(result);
 	}
 
 	send_unshallow(data);
@@ -900,7 +900,7 @@ static void deepen_by_rev_list(struct upload_pack_data *data,
 	disable_commit_graph(the_repository);
 	result = get_shallow_commits_by_rev_list(argv, SHALLOW, NOT_SHALLOW);
 	send_shallow(data, result);
-	free_commit_list(result);
+	commit_list_free(result);
 	send_unshallow(data);
 }
 
-- 
2.54.0.16.g8f27b399cbe

[PATCH v2 2/2] commit: remove deprecated functions

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

These functions were deprecated in a series of commits merged in
52882024 (Merge branch 'ps/commit-list-functions-renamed', 2026-02-13).

The compatibility was for in-flight topics at the time.

Acked-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---

Notes (series):
    v2: add ack

 commit.h | 19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/commit.h b/commit.h
index 58150045afa..5352056f87a 100644
--- a/commit.h
+++ b/commit.h
@@ -203,25 +203,6 @@ struct commit_list *commit_list_reverse(struct commit_list *list);
 
 void commit_list_free(struct commit_list *list);
 
-/*
- * Deprecated compatibility functions for `struct commit_list`, to be removed
- * once Git 2.53 is released.
- */
-static inline struct commit_list *copy_commit_list(struct commit_list *l)
-{
-	return commit_list_copy(l);
-}
-
-static inline struct commit_list *reverse_commit_list(struct commit_list *l)
-{
-	return commit_list_reverse(l);
-}
-
-static inline void free_commit_list(struct commit_list *l)
-{
-	commit_list_free(l);
-}
-
 struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
 
 const char *repo_logmsg_reencode(struct repository *r,
-- 
2.54.0.16.g8f27b399cbe

Re: [PATCH v2 0/2] commit: remove deprecated functions

[Jeff King]

On Thu, May 28, 2026 at 09:00:09AM +0200, kristofferhaugsbakk@fastmail.com wrote:

> Topic summary: Remove deprecated comments that were slated for removal
> after Git 2.53.0.

This looks obviously correct to me, but the whole topic made me wonder:
was it worth retaining the old names and deprecating them, versus just
removing them back then?

Topics in flight would have needed an update then, but they did
eventually anyway. So it feels like the total amount of work done is
larger, compared to just fixing them as the topics were merged. Either
way the compiler tells us, and the adjustments themselves are small.

Not a huge deal either way, but just pondering for future such
situations.

-Peff

Re: [PATCH v2 0/2] commit: remove deprecated functions

[Patrick Steinhardt]

On Fri, May 29, 2026 at 04:37:16AM -0400, Jeff King wrote:
> On Thu, May 28, 2026 at 09:00:09AM +0200, kristofferhaugsbakk@fastmail.com wrote:
> 
> > Topic summary: Remove deprecated comments that were slated for removal
> > after Git 2.53.0.
> 
> This looks obviously correct to me, but the whole topic made me wonder:
> was it worth retaining the old names and deprecating them, versus just
> removing them back then?
> 
> Topics in flight would have needed an update then, but they did
> eventually anyway. So it feels like the total amount of work done is
> larger, compared to just fixing them as the topics were merged. Either
> way the compiler tells us, and the adjustments themselves are small.
> 
> Not a huge deal either way, but just pondering for future such
> situations.

Yeah, I'm always very torn on these myself. I guess ultimately it's
always going to be dependent on the actual refactoring: the bigger the
blast radius, the more it makes sense to have a transition period so
that we don't break in-flight patch series.

Where exactly that line is is a different question of course.

Patrick

Re: [PATCH v2 0/2] commit: remove deprecated functions

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, May 28, 2026 at 09:00:09AM +0200, kristofferhaugsbakk@fastmail.com wrote:
>
>> Topic summary: Remove deprecated comments that were slated for removal
>> after Git 2.53.0.
>
> This looks obviously correct to me, but the whole topic made me wonder:
> was it worth retaining the old names and deprecating them, versus just
> removing them back then?
>
> Topics in flight would have needed an update then, but they did
> eventually anyway. So it feels like the total amount of work done is
> larger, compared to just fixing them as the topics were merged. Either
> way the compiler tells us, and the adjustments themselves are small.

Your alternative approach will depend on the integrator doing all
the fixups at the merge time.

The amount of effort required by the entire community as a whole may
have been larger, but the way the rename was carried out did spread
them thinner.

Admittedly, with help from rerere and merge-fix mechanism, such a
"fixup at the merge time" typically needs to be done only once per
the other conflicting topic in flight, but still, when constructing
a workflow, I try to avoid having to depend on the single bottleneck
for a task that does not need to be performed by the single
bottleneck, especially when the single bottleneck has other tasks
that can only be done by the single bottleneck.

> Not a huge deal either way, but just pondering for future such
> situations.
>
> -Peff

Re: [PATCH v2 0/2] commit: remove deprecated functions

[Jeff King]

On Mon, Jun 01, 2026 at 04:14:48PM +0900, Junio C Hamano wrote:

> > This looks obviously correct to me, but the whole topic made me wonder:
> > was it worth retaining the old names and deprecating them, versus just
> > removing them back then?
> >
> > Topics in flight would have needed an update then, but they did
> > eventually anyway. So it feels like the total amount of work done is
> > larger, compared to just fixing them as the topics were merged. Either
> > way the compiler tells us, and the adjustments themselves are small.
> 
> Your alternative approach will depend on the integrator doing all
> the fixups at the merge time.
> 
> The amount of effort required by the entire community as a whole may
> have been larger, but the way the rename was carried out did spread
> them thinner.

True, though my thinking was two-fold:

  - Topics in flight that you _haven't_ picked up yet are not your
    problem. They become the problem of their authors, as long as they
    build on top of the change in question (either originally, or via
    rebase).

  - It's also work to pick up the new topic. So there's some tradeoff
    for the maintainer in how many fixups (and how much effort for each
    one) versus the work to juggle a new topic.

> Admittedly, with help from rerere and merge-fix mechanism, such a
> "fixup at the merge time" typically needs to be done only once per
> the other conflicting topic in flight, but still, when constructing
> a workflow, I try to avoid having to depend on the single bottleneck
> for a task that does not need to be performed by the single
> bottleneck, especially when the single bottleneck has other tasks
> that can only be done by the single bottleneck.

Yeah, I think that is a good philosophy in general. I just wondered
whether the tradeoff was right here (but I'm happy to defer to you for
the final call on that).

-Peff