Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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'
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html