# [PATCH 0/2] commit: remove deprecated functions 13 messages from 2026-05-27 to 2026-06-02. Participants: kristofferhaugsbakk@fastmail.com, Patrick Steinhardt, Kristoffer Haugsbakk, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/65699 ## kristofferhaugsbakk@fastmail.com, 2026-05-27 13:59 Subject: [PATCH 0/2] commit: remove deprecated functions Message-ID: ``` From: Kristoffer Haugsbakk 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.com, 2026-05-27 13:59 Subject: [PATCH 1/2] *: replace deprecated free_commit_list Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk 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 --- 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 ``` ## kristofferhaugsbakk@fastmail.com, 2026-05-27 13:59 Subject: [PATCH 2/2] commit: remove deprecated functions Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk 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 --- 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 ``` ## Patrick Steinhardt, 2026-05-28 05:24 Subject: Re: [PATCH 1/2] *: replace deprecated free_commit_list Message-ID: In-Reply-To: ``` On Wed, May 27, 2026 at 03:59:25PM +0200, kristofferhaugsbakk@fastmail.com wrote: > From: Kristoffer Haugsbakk > > 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 > --- > 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 Steinhardt, 2026-05-28 05:24 Subject: Re: [PATCH 2/2] commit: remove deprecated functions Message-ID: In-Reply-To: ``` On Wed, May 27, 2026 at 03:59:26PM +0200, kristofferhaugsbakk@fastmail.com wrote: > From: Kristoffer Haugsbakk > > 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 Haugsbakk, 2026-05-28 06:49 Subject: Re: [PATCH 1/2] *: replace deprecated free_commit_list Message-ID: In-Reply-To: ``` 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) ``` ## kristofferhaugsbakk@fastmail.com, 2026-05-28 07:00 Subject: [PATCH v2 0/2] commit: remove deprecated functions Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk 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.com, 2026-05-28 07:00 Subject: [PATCH v2 1/2] *: replace deprecated free_commit_list Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk 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 Signed-off-by: Kristoffer Haugsbakk --- 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 ``` ## kristofferhaugsbakk@fastmail.com, 2026-05-28 07:00 Subject: [PATCH v2 2/2] commit: remove deprecated functions Message-ID: In-Reply-To: ``` From: Kristoffer Haugsbakk 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 Signed-off-by: Kristoffer Haugsbakk --- 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 ``` ## Jeff King, 2026-05-29 08:37 Subject: Re: [PATCH v2 0/2] commit: remove deprecated functions Message-ID: <20260529083716.GE1106035@coredump.intra.peff.net> In-Reply-To: ``` 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 Steinhardt, 2026-06-01 05:58 Subject: Re: [PATCH v2 0/2] commit: remove deprecated functions Message-ID: In-Reply-To: <20260529083716.GE1106035@coredump.intra.peff.net> ``` 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 ``` ## Junio C Hamano, 2026-06-01 07:14 Subject: Re: [PATCH v2 0/2] commit: remove deprecated functions Message-ID: In-Reply-To: <20260529083716.GE1106035@coredump.intra.peff.net> ``` Jeff King 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 ``` ## Jeff King, 2026-06-02 06:23 Subject: Re: [PATCH v2 0/2] commit: remove deprecated functions Message-ID: <20260602062322.GB695568@coredump.intra.peff.net> In-Reply-To: ``` 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 ```