Elijah Newren <newren@xxxxxxxxx> writes: > On Fri, Apr 15, 2022 at 10:41 PM Edmundo Carmona Antoranz > <eantoranz@xxxxxxxxx> wrote: >> >> On Fri, Apr 15, 2022 at 10:33 PM Junio C Hamano <gitster@xxxxxxxxx> 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, It silently drops user changes as well, and that's the worst thing about it, not annoyance. > whereas the latter can silently discard changes or reintroduce > discarded changes and could be dangerous. More details on both of > these... Please consider yet another option: https://public-inbox.org/git/87r2oxe3o1.fsf@xxxxxxxxx/ that at least is safe with respect to user changes. -- Sergey Organov
