Re: [RFC] introducing git replay

Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:

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.