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. > > Michael > > [1] > http://softwareswirl.blogspot.de/2009/04/truce-in-merge-vs-rebase-war.html > > -- > Michael Haggerty > mhagger@xxxxxxxxxxxx > -- 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