Re: [PATCH 7/8] builtin/history: split out extended function to create commits

[Patrick Steinhardt <ps@pks.im>]

On Tue, Mar 03, 2026 at 01:43:12PM -0500, D. Ben Knoble wrote:
> On Mon, Mar 2, 2026 at 7:17 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > In the next commit we're about to introduce a new command that splits up
> > a commit into two. Most of the logic will be shared with rewording
> > commits, except that we also need to have control over the parents and
> > the old/new trees.
> >
> > Extract a new function `commit_tree_with_edited_message_ext()` to
> > prepare for this commit.
> 
> Curious—what's the "ext" suffix mean here. Extracted? External? (Maybe
> I'll get a better clue in the next patch.)

It stands for "extended". I thought that this was already common use in
our code base:

  - `refs_for_each_ref_ext()`
  - `odb_write_object_ext()`
  - `peel_object_ext()`

But Junio recently asked the same, so maybe I'm biased here (I am, two
of these functions are my doing). Happy to take an alternative suffix.

Patrick