Re: Idea for rebase strategy
- From
Andy Whitcroft <apw@shadowen.org>
- Date
- Nov 27, 2006, 09:02 UTC
- Message-ID
- <456AA9B2.8050409@shadowen.org>
- In-Reply-To
- <7vfyc5l24t.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 39 quoted lines
> 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.