Re: [PATCH v9 4/7] replay: yield the object ID of the final rewritten commit
- From
Elijah Newren <newren@gmail.com>
- Date
- Jan 10, 2026, 01:17 UTC
- Message-ID
- <CABPp-BFXsZe5k-2qbkTfMaU7xxpViiHACOG+vwiRnf9xemd0QA@mail.gmail.com>
- In-Reply-To
- <20260109-b4-pks-history-builtin-v9-4-8766101814c6@pks.im>
On Fri, Jan 9, 2026 at 12:35 AM Patrick Steinhardt <ps@pks.im> wrote:
Show 5 quoted lines
> > 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?
Show 49 quoted lines
> 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 <ps@pks.im>
> ---
> 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?