From: Patrick Steinhardt <ps@pks.im>
Date: Mon, 12 Jan 2026 13:03:19 GMT
Subject: Re: [PATCH v9 4/7] replay: yield the object ID of the final rewritten commit
Message-ID: <aWTxF0xRiCm49lng@pks.im>
In-Reply-To: <CABPp-BFXsZe5k-2qbkTfMaU7xxpViiHACOG+vwiRnf9xemd0QA@mail.gmail.com>

On Fri, Jan 09, 2026 at 05:17:02PM -0800, Elijah Newren wrote:
> On Fri, Jan 9, 2026 at 12:35 AM Patrick Steinhardt <ps@pks.im> wrote:
> > diff --git a/replay.h b/replay.h
> > index 84bc8a7a5b..f8f9889112 100644
> > --- a/replay.h
> > +++ b/replay.h
> > @@ -46,6 +46,22 @@ struct replay_result {
> >
> >         /* Set to true in case the replay failed with a merge conflict. */
> >         bool merge_conflict;
> > +
> > +       /*
> > +        * The final object ID that was rewritten. Note that this field has
> > +        * somewhat special semantics and may or may not be what you want:
> > +        *
> > +        *   - If no commits were rewritten it will remain uninitialized.
> > +        *
> > +        *   - If a thicket of branches is rewritten it is undefined in which
> > +        *     order those branches will be rewritten, and thus the final object
> > +        *     ID may point to a different commit than you'd expect.
> > +        *
> > +        * That being said, this field can still be useful when you know that
> > +        * you only replay a single strand of commits. In that case, the final
> > +        * commit will point to the tip of the rewritten strand of commits.
> > +        */
> > +       struct object_id final_oid;
> >  };
> 
> I don't understand why this is needed for the usecase you provide.
> Are you perhaps trying to rewrite a set of commits whose tip is not a
> branch or something (directly contradicting your first paragraph of
> the commit message)?  That's the only case I can think of where this
> would be useful, unless I'm missing something?

It's the case where you're rewriting a detached HEAD. But I'll discard
this commit in favor of what you've posted.

Thanks!

Patrick