From: Elijah Newren Date: Sat, 10 Jan 2026 01:17:02 GMT Subject: Re: [PATCH v9 4/7] replay: yield the object ID of the final rewritten commit Message-ID: In-Reply-To: <20260109-b4-pks-history-builtin-v9-4-8766101814c6@pks.im> On Fri, Jan 9, 2026 at 12:35 AM Patrick Steinhardt wrote: > > In a subsequent commit we'll introduce a new git-history(1) command that > uses the replay machinery to rewrite commits. One of its supported modes > will only want to update the "HEAD" reference, but that is not currently > supported by the replay machinery. I'm a little surprised. In that case replay_result->updates_nr would be 1 and you'd just use replay_result->updates[0], right? > Allow implementing this use case by exposing a `final_oid` field for the > reference updates. This field will be set to the last commit that was > rewritten, which is sufficient information for us to implement this mode > in git-history(1). > > Signed-off-by: Patrick Steinhardt > --- > replay.c | 2 ++ > replay.h | 16 ++++++++++++++++ > 2 files changed, 18 insertions(+) > > diff --git a/replay.c b/replay.c > index 313fb2a768..20560e792b 100644 > --- a/replay.c > +++ b/replay.c > @@ -338,6 +338,8 @@ int replay_revisions(struct repository *repo, struct rev_info *revs, > &onto->object.oid, > &last_commit->object.oid); > > + out->final_oid = last_commit->object.oid; > + > ret = 0; > > out: > 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?