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

The Git List

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

patch, 2 partscommit: remove deprecated functions

13 messages between May 27, 2026 and Jun 2, 2026, from kristofferhaugsbakk@fastmail.com, Patrick Steinhardt, Kristoffer Haugsbakk, Jeff King, Junio C Hamano.

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

kristofferhaugsbakk@fastmail.comMay 27, 2026, 13:59 UTC on lore
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
kristofferhaugsbakk@fastmail.comMay 27, 2026, 13:59 UTC in reply to kristofferhaugsbakk@fastmail.com on lore

[PATCH 1/2] *: replace deprecated free_commit_list

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

builtin/history.c, replay.c, upload-pack.c

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
kristofferhaugsbakk@fastmail.comMay 27, 2026, 13:59 UTC in reply to kristofferhaugsbakk@fastmail.com on lore

[PATCH 2/2] commit: remove deprecated functions

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(-)
Show changes to commit.h +0 −19
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
Patrick SteinhardtMay 28, 2026, 05:24 UTC in reply to kristofferhaugsbakk@fastmail.com on lore

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

On Wed, May 27, 2026 at 03:59:25PM +0200, kristofferhaugsbakk@fastmail.com wrote:
Show 19 quoted lines
> 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
Patrick SteinhardtMay 28, 2026, 05:24 UTC in reply to kristofferhaugsbakk@fastmail.com on lore

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

On Wed, May 27, 2026 at 03:59:26PM +0200, kristofferhaugsbakk@fastmail.com wrote:
Show 6 quoted lines
> 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
Kristoffer HaugsbakkMay 28, 2026, 06:49 UTC in reply to Patrick Steinhardt on lore

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

On Thu, May 28, 2026, at 07:24, Patrick Steinhardt wrote:
Show 10 quoted lines
> 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)

kristofferhaugsbakk@fastmail.comMay 28, 2026, 07:00 UTC in reply to kristofferhaugsbakk@fastmail.com on lore

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

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
kristofferhaugsbakk@fastmail.comMay 28, 2026, 07:00 UTC in reply to kristofferhaugsbakk@fastmail.com on lore

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

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

builtin/history.c, replay.c, upload-pack.c

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
kristofferhaugsbakk@fastmail.comMay 28, 2026, 07:00 UTC in reply to kristofferhaugsbakk@fastmail.com on lore

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

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(-)
Show changes to commit.h +0 −19
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
Jeff KingMay 29, 2026, 08:37 UTC in reply to kristofferhaugsbakk@fastmail.com on lore

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

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
Patrick SteinhardtJun 1, 2026, 05:58 UTC in reply to Jeff King on lore

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

On Fri, May 29, 2026 at 04:37:16AM -0400, Jeff King wrote:
Show 16 quoted lines
> 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
Junio C HamanoJun 1, 2026, 07:14 UTC in reply to Jeff King on lore

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

Jeff King <peff@peff.net> writes:
Show 13 quoted lines
> 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
Jeff KingJun 2, 2026, 06:23 UTC in reply to Junio C Hamano on lore

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

On Mon, Jun 01, 2026 at 04:14:48PM +0900, Junio C Hamano wrote:
Show 15 quoted lines
> > 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.
Show 7 quoted lines
> 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

Back to recent threads