Re: [RFC] introducing git replay

From: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Date: Apr 15, 2022, 18:46 UTC
Message-ID: <CAOc6etYvOhqQn3icWj3Ny1m+J_60h7aiqW-gvm=dQyDLgG=6NA@mail.gmail.com>
In-Reply-To: <xmqq4k2wap8g.fsf@gitster.g>

On Wed, Apr 13, 2022 at 7:05 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

>
>
> Also, if this _were_ to allow recreating the shape of the history,
> using updated tips of branches that were merged in the original
> history, perhaps taking hints from "Merge branch X into Y" in the
> original merge commit's log messages, that would be quite useful
> addition to the rebase mechanism, but this is not that.

Ok.... I have taken some time to read it through in calm and this part is making my head scratch because it sounds like the stuff that I had in mind in replay (or if we move it into rebase or any other place). So, to clarify what you are asking, when replaying _a given commit_:

- If a parent is included in the history of the _old_ base, you would
like to see it included as is (no changes) as a parent of the replayed
commit.
- If a parent is not included in the history of the _old base_, it
means it has been replayed and we need to take the equivalent replayed
commit of the parent.

So, coming back to the example:

git replay HEAD v2.35.0 v2.36.0-rc1

We would replay all commits that make up the range v2.35.0..v2.36.0-rc1

Now, for any given commit being replayed, if a parent is in that range, it would use the replayed commit of the parent. If the parent is not in that range (which means that it's part of the history of v2.35.0, which is not being replayed) then we need to take it as-is straight no changes which means that _the original_ parent commit will be linked in the resulting replayed commit that we are working on at the time therefore linking the original history. (sorry if it sounds a little bit reiterative).

Is that what you mean? Because, if that is the case, that is what replay does as of this patch.

If you gave it a try like in the eample, you should end up with a commit (the one reported at the end of the execution) that has the _exact same_ history shape of v2.36.0-rc1 (even linking to commits that are part of the history of v2.35.0).

But I am probably wrong in terms of what I understand that you meant. Can you expand a little bit, if you don't mind?