{"thread":{"id":"43492","subject":"Re: Idea for rebase strategy","startedAt":"2006-11-27T00:15:14Z","lastAt":"2006-11-27T23:40:16Z","messageCount":5,"participants":["Johannes Schindelin","Junio C Hamano","Andy Whitcroft"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298355","messageId":"Pine.LNX.4.63.0611270108160.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43492","inReplyTo":null,"subject":"Idea for rebase strategy","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-27T00:15:14Z","receivedAt":"2006-11-27T00:15:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nan idea hit me today: maybe we can make rebase work nicely with merges \nafter all. We could record the original branch point and the new branch \npoint for rebases.\n\nIf this information is somehow accessible when doing a merge, git could \ncheck if the old branch point is reachable from the current HEAD, but not \nthe new branch point, and if both are the case, rebase the changes since \nthe old branch point on top of the new branch point before trying to \nmerge.\n\nDoes this sound too far-fetched?\n\nCiao,\nDscho\n"},{"id":"296625","messageId":"7vfyc5l24t.fsf@assigned-by-dhcp.cox.net","threadId":"43492","inReplyTo":"Pine.LNX.4.63.0611270108160.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Idea for rebase strategy","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-27T08:33:54Z","receivedAt":"2006-11-27T08:33:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> an idea hit me today: maybe we can make rebase work nicely with merges \n> after all. We could record the original branch point and the new branch \n> point for rebases.\n\nOne case that that would be simple enough, appear often enough\nin real life, and would be useful in practice is this:\n\n A---B---C---D---E topic\n / /\n ---X---o---Y---Z master\n\nAfter forking 'topic' at 'X' and built two commits A and B, the\nmaster has a related change in the area 'topic' works on, and a\nmerge to adjust is made at C. Then it builds two other commits\nD and E. We should be able to rebase it on top of the master.\n\nIf we have a reliable ref-log for 'topic' that should be trivial\nto do. It will be just the matter of replaying the log on top\nof master. The ref-log says we committed two after we forked,\nso we replay them:\n\n A---B---C---D---E topic\n / /\n ---X---o---Y---Z master\n \\\n A'--B'\n\nThen the log says we merged 'Y'. We faithfully replay that,\nwhich wuold result in \"fast-forward -- nothing special is\nneeded\" situation. The remaining log entries would say we have\ntwo further commits, so replaying them would result in:\n\n A---B---C---D---E topic\n / /\n ---X---o---Y---Z master\n \\\n A'--B'--C'--D' topic'\n\n"},{"id":"297944","messageId":"456AA9B2.8050409@shadowen.org","threadId":"43492","inReplyTo":"7vfyc5l24t.fsf@assigned-by-dhcp.cox.net","subject":"Re: Idea for rebase strategy","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-27T09:02:42Z","receivedAt":"2006-11-27T09:02:42Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n>> an idea hit me today: maybe we can make rebase work nicely with merges \n>> after all. We could record the original branch point and the new branch \n>> point for rebases.\n> \n> One case that that would be simple enough, appear often enough\n> in real life, and would be useful in practice is this:\n> \n> A---B---C---D---E topic\n> / /\n> ---X---o---Y---Z master\n> \n> After forking 'topic' at 'X' and built two commits A and B, the\n> master has a related change in the area 'topic' works on, and a\n> merge to adjust is made at C. Then it builds two other commits\n> D and E. We should be able to rebase it on top of the master.\n> \n> If we have a reliable ref-log for 'topic' that should be trivial\n> to do. It will be just the matter of replaying the log on top\n> of master. The ref-log says we committed two after we forked,\n> so we replay them:\n> \n> A---B---C---D---E topic\n> / /\n> ---X---o---Y---Z master\n> \\\n> A'--B'\n> \n> Then the log says we merged 'Y'. We faithfully replay that,\n> which wuold result in \"fast-forward -- nothing special is\n> needed\" situation. The remaining log entries would say we have\n> two further commits, so replaying them would result in:\n> \n> A---B---C---D---E topic\n> / /\n> ---X---o---Y---Z master\n> \\\n> A'--B'--C'--D' topic'\n\nInterestingly this trivial situation seems to works pretty much as is.\nA \"git rebase --onto master X topic\" (at least in my trivial test case)\nreplayed A and B, squashed C as a noop, and copied D and E. I did not\nneed any information from the reflog. Of course the reflog is a good\nway to find X as its first transaction but I did not need it to drive\nreplay.\n\n"},{"id":"295678","messageId":"7vfyc5i6k4.fsf@assigned-by-dhcp.cox.net","threadId":"43492","inReplyTo":"456AA9B2.8050409@shadowen.org","subject":"Re: Idea for rebase strategy","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-27T09:26:35Z","receivedAt":"2006-11-27T09:26:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Whitcroft writes:\n\n>> \n>> A---B---C---D---E topic\n>> / /\n>> ---X---o---Y---Z master\n>> \\\n>> A'--B'--C'--D' topic'\n>\n> Interestingly this trivial situation seems to works pretty much as is.\n> A \"git rebase --onto master X topic\" (at least in my trivial test case)\n> replayed A and B, squashed C as a noop, and copied D and E. I did not\n> need any information from the reflog. Of course the reflog is a good\n> way to find X as its first transaction but I did not need it to drive\n> replay.\n\nThat is only because the pictures are showing the degenerated\ncase for simplicity, and the defect that the current rebase does\nnot even look at any merges is hidden by the fact that the merge\nin the example C becomes no-op in the rebased history. C could\nbe somewhere not between X and Z, in which case replaying the\nmerge becomes necessary. Also when following from E to traverse\ndown the history of topic, at point C, you need to tell which of\nB or Y are on the topic, and that's where you would rely on\nref-log.\n\n\n"},{"id":"295102","messageId":"Pine.LNX.4.63.0611280037200.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43492","inReplyTo":"7vfyc5l24t.fsf@assigned-by-dhcp.cox.net","subject":"Re: Idea for rebase strategy","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-27T23:40:16Z","receivedAt":"2006-11-27T23:40:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 27 Nov 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > an idea hit me today: maybe we can make rebase work nicely with merges \n> > after all. We could record the original branch point and the new branch \n> > point for rebases.\n> \n> [...]\n> \n> If we have a reliable ref-log for 'topic' that should be trivial\n> to do.\n\nBut of course! Yet another reason to introduce core.disableRefLog, and \nturn it on by default...\n\nThe graceful merging of a rebased branch indeed depends on the local \nhistory, i.e. what is stored in the reflog.\n\nCiao,\nDscho\n"}]}