Re: [PATCH] add -i: hide init/clear_add_i_state() functions

[Patrick Steinhardt <ps@pks.im>]

On Fri, Oct 30, 2026 at 05:35:20PM -0400, Ben Knoble wrote:
> 
> > Le 30 oct. 2026 à 11:30, Junio C Hamano <gitster@pobox.com> a écrit :
> > 
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> >>> On Wed, Oct 28, 2026 at 12:57:51PM -0700, Junio C Hamano wrote:
> >>> The "add -i" machinery is encapsulated in run_add_i() function,
> >>> which uses init_add_i_state() to initialize the machinery, does its
> >>> thing, and clear_add_i_state() to tear it down.  External callers
> >>> have no need to call anything other than run_add_i().
> >>> 
> >>> Make init/clear_add_i_state() file-scope static functions, and
> >>> "struct add_i_state" type as well.
> >> 
> >> Nice cleanup. For historical context, these declarations are not needed
> >> anymore starting with d51b61f5dab (add-patch: remove dependency on
> >> "add-interactive" subsystem, 2026-03-02).
> > 
> > Thanks.  I did not notice that I gave a backstory for the other
> > three commits but apparently did so without digging into the history
> > for this one.
> > 
> > By the way, I queued the patches sent to the list on a branch (I
> > initially made them on a detached HEAD without keeping a local copy
> > after sending them out) and tried 'git history reword' to update
> > this one, but it seems it does not honor the notes.rewriteref
> > configuration variable.  I wonder if this is a known limitation, or
> > a deliberate design.
> 
> Indeed. I believe it is a known limitation (one I would love to
> lift, but will probably not dedicate time to produce code soon).
> Still, I’ll help in the usual ways if I can ;)

Yeah, it's a limitation and not a design decision. I'd be happy to
review any such patch series, as I'm also a bit short on time recently.
Meanwhile I've also created an issue in our bug tracker, so we may pick
this up in the next release cycle.

Patrick