Re: Idea for rebase strategy

From: Junio C Hamano <junkio@cox.net>
Date: Nov 27, 2006, 08:33 UTC
Message-ID: <7vfyc5l24t.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0611270108160.30004@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> an idea hit me today: maybe we can make rebase work nicely with merges 
> after all. We could record the original branch point and the new branch 
> point for rebases.

One case that that would be simple enough, appear often enough in real life, and would be useful in practice is this:

       A---B---C---D---E topic
      /       /
  ---X---o---Y---Z master

After forking 'topic' at 'X' and built two commits A and B, the master has a related change in the area 'topic' works on, and a merge to adjust is made at C. Then it builds two other commits D and E. We should be able to rebase it on top of the master.

If we have a reliable ref-log for 'topic' that should be trivial to do. It will be just the matter of replaying the log on top of master. The ref-log says we committed two after we forked, so we replay them:

       A---B---C---D---E topic
      /       /
  ---X---o---Y---Z master
                  \
                   A'--B'

Then the log says we merged 'Y'. We faithfully replay that, which wuold result in "fast-forward -- nothing special is needed" situation. The remaining log entries would say we have two further commits, so replaying them would result in:

       A---B---C---D---E topic
      /       /
  ---X---o---Y---Z master
                  \
                   A'--B'--C'--D' topic'