Re: [RFC] introducing git replay

[Edmundo Carmona Antoranz <eantoranz@gmail.com>]

On Sun, Apr 17, 2022 at 7:05 AM Elijah Newren <newren@gmail.com> wrote:
>
>
> Replaying merges is something I've put a little thought into, so allow
> me to provide some pointers that may help.  Merges need special
> handling for replaying, and in my opinion, doing either just a new
> merge of the new trees (what rebase --rebase-merges does), or just
> reusing existing trees (what you proposed to start this thread) are
> both suboptimal, though the former is likely to just be annoying and
> require potentially unnecessary user refixing, whereas the latter can
> silently discard changes or reintroduce discarded changes and could be
> dangerous.  More details on both of these...
>
> An important part about merges is they may have resolved conflicts --
> both textual (the standard conflict markers people have to resolve)
> and semantic (e.g. one person changes the API of some function, and
> the other branch being merged adds a caller of that function, so the
> merge has to modify the new caller to use the new API).  We do not
> just want to do a new merge and re-use the commit message (as rebase
> --rebase-merges does), for two reasons: (1) the user either has to
> re-resolve the textual conflict resolutions by hand, or use rerere
> which requires a working tree (and we'd like replays to proceed
> without a working tree where possible), and (2) it tosses semantic
> merge conflict resolutions entirely.  We also do not just want to use
> existing trees as-is (as you started with in your patch), for three
> reasons: (1) when we move to a new base the new merge needs to include
> the changes from the newer base, (2) the topic might have additional
> changes added (or removed) during the "rebase" which need to be
> reflected in the merge as well, and (3) the merge may have had
> additional changes stuffed directly into it to solve semantic
> conflicts which we want "ported" to the new merge commit.    So, for
> handling merges, we should avoid both of these overly simplistic
> mechanisms, and do something that tries to handle forward-porting
> these conflict resolutions.  I have outlined steps to do so at
> https://lore.kernel.org/git/CABPp-BHp+d62dCyAaJfh1cZ8xVpGyb97mZryd02aCOX=Qn=Ltw@mail.gmail.com/
>

Hey, Elijah! Thanks for taking the time and the feedback.

Forget about me introducing replay as a separate command as a "real"
proposal. My intent (and which I saw most simple to be able to show
it) was to present the idea of an optimization (if you will) to the
rebase mechanism under certain rather narrow conditions:

git rebase --onto A B C

if A^{tree} == B^{tree} that means that we could create an equivalent
commit for the segment B..C on top of A without much hassle by reusing
the same trees from that segment (no need to calculate new trees...and
no need to move along the working tree as we are creating those
commits).

My impression from reading your feedback is that you have a much
broader scope in terms of what you want to achieve.So, for the time
being, I will work on trying to get the optimization in rebase and see
how far I am able to move it forward.... and you are able to keep
replay as a separate command if that is your will for the
not-so-distant future. :-)

BR!

PS I will be snooping around all of that material you are linking as I
am sure there will be interesting stuff in there. And thanks, again!