Re: [RFC] introducing git replay

> On Fri, Apr 15, 2022 at 10:41 PM Edmundo Carmona Antoranz
> <eantoranz@gmail.com> wrote:
>>
>> On Fri, Apr 15, 2022 at 10:33 PM Junio C Hamano <gitster@pobox.com> wrote:
>> >
>> > It would be wonderful if a single command like replay can be used to
>> > say "In the old history master..seen I have bunch of merges.  master
>> > used to be M but now it is at N.  Rebuild M..S on top of N _but_
>> > with a bit of twist.  Some of the topics in M...S may have been
>> > merged to 'master' between M..N and the replayed history on top of N
>> > does not want to have a merge from such 'already graduated' topics.
>> > Many topics are updated, either by adding a new commit on top or
>> > completely rewritten, and we want an updated tip of these topic
>> > branches, not the old tip that I merged when I created M..S chain,
>> > when replaying the history on top of N."
>> >
>> > That kind of operation is quite different from what "rebase" does,
>> > and deserves to be under a different name.
>> >
>>
>> Let me work a little bit on your workflow to see what I can do.
>
> 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,