<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2015-10-14 10:14 GMT+02:00 David Turner <span dir="ltr"><<a href="mailto:dct25-561bs@mythic-beasts.com" target="_blank">dct25-561bs@mythic-beasts.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>[...] It's very hard for either A or B to reason about the correctness of that last step because it's such a big change. On the other hand, rebasing B's changes on top of A's looks like this:<br></div><div><br></div><div><font face="monospace, monospace">A1 -> A2 -> .... -> An -> B1' -> B2' -> .... -> Bm'</font></div><div><br></div><div>Then B can go through their rebased changes and use pretty much the same reasoning as they were using before to check that they're still correct.</div></div></div></blockquote><div><br></div><div>And what's even better: If you have a sane set of tests, you can easily find the exact commit where things went wrong in an automated way via 'git bisect'. This is the reason why some companies with large code bases totally ban merge commits and rely on rebasing exclusively. You can even go a step further by e.g. trying to revert the guilty commit and see if things work again without it, again in a totally automated way.</div></div></div></div>