commit: remove deprecated functions
cover commit: remove deprecated functions
From: Kristoffer Haugsbakk <[email protected]>
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
[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
Signature · 1 line
2.54.0.6.gf6fa7dd4140
PATCH 1/2 *: replace deprecated free_commit_list
From: Kristoffer Haugsbakk <[email protected]>
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
--- builtin/history.c | 4 ++-- replay.c | 2 +- upload-pack.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-)
builtin/history.c +2 -2
@@ -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; }
replay.c +1 -1
@@ -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;
upload-pack.c +2 -2
@@ -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); }
Signature · 1 line
2.54.0.6.gf6fa7dd4140
Re: [PATCH 1/2] *: replace deprecated free_commit_list
Quoted 13 lines · On Wed, May 27, 2026 at 03:59:25PM +0200, [email protected]…
From: Kristoffer Haugsbakk <[email protected]>
Replace
free_commit_listwithcommit_list_free. The former was deprecated in9f18d089(commit: renamefree_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
Quoted 6 lines
Signed-off-by Kristoffer Haugsbakk <[email protected]>--- 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
Quoted 10 lines · Patrick Steinhardt
On Wed, May 27, 2026 at 03:59:25PM +0200,
Quoted 6 lines
[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
In reply to [email protected]From: Kristoffer Haugsbakk <[email protected]>
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.
--- commit.h | 19 ------------------- 1 file changed, 19 deletions(-)
commit.h +0 -19
@@ -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,
Signature · 1 line
2.54.0.6.gf6fa7dd4140
Quoted 6 lines · On Wed, May 27, 2026 at 03:59:26PM +0200, [email protected]…
From: Kristoffer Haugsbakk <[email protected]>
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
v2 cover commit: remove deprecated functions
In reply to [email protected]From: Kristoffer Haugsbakk <[email protected]>
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
§ Changes v2
Add ack by Patrick, the author of these compatibility functions.
§ Link to v1
https://lore.kernel.org/git/[email protected]/#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
Signature · 1 line
2.54.0.16.g8f27b399cbe
PATCH v2 1/2 *: replace deprecated free_commit_list
From: Kristoffer Haugsbakk <[email protected]>
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
---
Notes (series):
v2: add ack
builtin/history.c | 4 ++-- replay.c | 2 +- upload-pack.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-)
builtin/history.c +2 -2
@@ -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; }
replay.c +1 -1
@@ -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;
upload-pack.c +2 -2
@@ -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); }
Signature · 1 line
2.54.0.16.g8f27b399cbe
PATCH v2 2/2 commit: remove deprecated functions
In reply to [email protected]From: Kristoffer Haugsbakk <[email protected]>
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.
---
Notes (series):
v2: add ack
commit.h | 19 ------------------- 1 file changed, 19 deletions(-)
commit.h +0 -19
@@ -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,
Signature · 1 line
2.54.0.16.g8f27b399cbe
Quoted 2 lines · On Thu, May 28, 2026 at 09:00:09AM +0200, [email protected]…
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
Quoted 9 lines · Jeff King
Quoted 2 lines · On Thu, May 28, 2026 at 09:00:09AM +0200, [email protected]…
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?
Quoted 7 lines
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
Quoted 5 lines · Jeff King
Quoted 2 lines · On Thu, May 28, 2026 at 09:00:09AM +0200, [email protected]…
Topic summary: Remove deprecated comments that were slated for removal after Git 2.53.0.
Quoted 8 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.
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.
Quoted 4 lines
Not a huge deal either way, but just pondering for future such situations.
-Peff
Quoted 9 lines · Junio C Hamano
Quoted 8 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.
Quoted 6 lines
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.
Quoted 7 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