Re: Idea for rebase strategy

[Andy Whitcroft <apw@shadowen.org>]

Junio C Hamano wrote:
> 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'

Interestingly this trivial situation seems to works pretty much as is.
A "git rebase --onto master X topic" (at least in my trivial test case)
replayed A and B, squashed C as a noop, and copied D and E.  I did not
need any information from the reflog.  Of course the reflog is a good
way to find X as its first transaction but I did not need it to drive
replay.