Re: [PATCH v9 4/7] replay: yield the object ID of the final rewritten commit
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Jan 12, 2026, 13:03 UTC
- 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:
Show 32 quoted lines
> 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