Edmundo Carmona Antoranz <eantoranz@xxxxxxxxx> writes:
> 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?
What I had in mind is what I have to do every day multiple times.
'master'..'seen' is a series of merges of tips of different topic
branches.
---T topic
\
\ \ \ \
--M---o----o----o----S seen
^
master
Some of the topic branches may get updated and 'master' may gain
more commits by merging some topics. Now it is time to update the
'master'..'seen' chain.
---T---P topic (updated)
\
\ \ \ \
--M---o----o----o----S seen
\
o
\
N
master
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.
Compared to that, "replay exactly the same set of commits in the
same shape on top of a different commit whose tree happens to be the
same as the original", is a mere special case of "rebase" that is
not all that interesting. It may be a worthwhile thing to do to
teach "rebase" capable of doing so reliably and more efficiently,
but that still falls into "improving rebase" category, not meriting
a separate command.
