Re: [RFC] introducing git replay

From: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Date: Apr 17, 2022, 05:37 UTC
Message-ID: <CAOc6etb7fmO2FAv09+wHsDBwnLsBi+B-CwRarm2tfYS-aUWcfg@mail.gmail.com>
In-Reply-To: <CABPp-BE=H-OcvGNJKm2zTvV3jEcUV0L=6W76ctpwOewZg56FKg@mail.gmail.com>

On Sun, Apr 17, 2022 at 7:05 AM Elijah Newren <newren@gmail.com> wrote:

Show 35 quoted lines

>
>
> 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!