On Mon, May 11, 2015 at 7:10 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Sun, May 10, 2015 at 11:52 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >> This is exactly the kind of case that "rebase with history" [1] was >> meant to address. But given that our tooling doesn't support such >> complicated histories very well, your plan sounds reasonable. > > As a side note to your blog post unrelated to the current series: > > I think the new proposed history for "rebase-by-merging-a-patch-at-a-time" also > improves bisectability because you have less long running side branches > (as compared to both in traditional rebase and traditional merge), but a finer > meshed DAG where it is easier to split the commit range into half its size. > When going back one step in history you have more merge nodes where > bisect can decide how many commits to chop off of the new range. Yeah, this was discussed at the Git Merge 2013 in Berlin, where Michael gave two presentations (one on the developer day and one on the user day) about git-imerge. We also discussed the idea of using a replace ref to be able to switch between different "views" of the merge, for example one view where you see only one commit for the whole merge/rebase with history, and one view where you see all the micro merge commits. Best, Christian. -- 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