Re: [PATCH 01/12] rerere: rename `repo_rerere()`

[Patrick Steinhardt <ps@pks.im>]

On Tue, Oct 27, 2026 at 12:48:36PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > The `repo_rerere()` function is the only function in "rerere.h" that
> > does not have a `rerere_` prefix. And while it does indeed receive a
> > repository as first parameter, that's not a good-enough reason to give
> > it a `repo_` prefix.
> >
> > Rename the function to `rerere_record()` to be consistent with all the
> > other functions.
> 
> I do not think the convention to give "repo_" prefix to variants of
> functions that worked only on the_repository should stay with us
> forever, and losing repo prefix from this function would be an
> excellent first move towards that future.
> 
> I howevr take isseus with the verb "record" in its new name.  What
> the function does is not just record.  It autonomously finds out
> what situation it is in and does the logical next thing, which
> varies.  It resolves when a recorded resolution exist.  it records
> when seeing a particular conflict for the first time.  There was no
> single good verb to express that.  Perhaps "to rerere" or "to
> perform rerere" can be invented as a verb to describe such an
> intelligent operation?

I was picking "record" because that's also what git-rerere(1) says:

  This command assists the developer in this process by recording
  conflicted automerge results and corresponding hand resolve results on
  the initial manual merge, and applying previously recorded hand
  resolutions to their corresponding automerge results.

But I guess your point is valid, as we don't only do that, but also
update merge conflicts locally. I'd pick your "perform" proposal in that
case and rename it to `rerere_perform()` instead. That name is somewhat
vague, but I guess that cannot be helped because it actually does a
bunch of things at once.

I guess that can be helped with documentation though.

Patrick