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

From: Patrick Steinhardt <ps@pks.im>
Date: Mar 11, 2026, 09:26 UTC
Message-ID: <abE1NwXLCsXanSjy@pks.im>
In-Reply-To: <CALnO6CC5FB29bHPtyKD=L5EWxTCLx3K2qd+wGySdck7tCvvs_w@mail.gmail.com>

On Tue, Mar 03, 2026 at 01:43:12PM -0500, D. Ben Knoble wrote:

Show 12 quoted lines

> 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