Idea for rebase strategy

Idea for rebase strategy

[Johannes Schindelin]

Hi,

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.

If this information is somehow accessible when doing a merge, git could 
check if the old branch point is reachable from the current HEAD, but not 
the new branch point, and if both are the case, rebase the changes since 
the old branch point on top of the new branch point before trying to 
merge.

Does this sound too far-fetched?

Ciao,
Dscho

Re: Idea for rebase strategy

[Junio C Hamano]

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'

Re: Idea for rebase strategy

[Andy Whitcroft]

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.

Re: Idea for rebase strategy

[Junio C Hamano]

Andy Whitcroft <apw@shadowen.org> writes:

>> 
>>        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.

That is only because the pictures are showing the degenerated
case for simplicity, and the defect that the current rebase does
not even look at any merges is hidden by the fact that the merge
in the example C becomes no-op in the rebased history.  C could
be somewhere not between X and Z, in which case replaying the
merge becomes necessary.  Also when following from E to traverse
down the history of topic, at point C, you need to tell which of
B or Y are on the topic, and that's where you would rely on
ref-log.

Re: Idea for rebase strategy

[Johannes Schindelin]

Hi,

On Mon, 27 Nov 2006, 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.
> 
> [...]
> 
> If we have a reliable ref-log for 'topic' that should be trivial
> to do.

But of course! Yet another reason to introduce core.disableRefLog, and 
turn it on by default...

The graceful merging of a rebased branch indeed depends on the local 
history, i.e. what is stored in the reflog.

Ciao,
Dscho