Re: [RFC] introducing git replay

[Junio C Hamano <gitster@pobox.com>]

Edmundo Carmona Antoranz <eantoranz@gmail.com> 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.