Re: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design

On 14 October 2015 at 11:51, Sven Panne wrote:

2015-10-14 10:14 GMT+02:00 David Turner :

...

[...] 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:

A1 -> A2 -> .... -> An -> B1' -> B2' -> .... -> Bm'

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.

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.

I'm not sure why you're saying this is impossible with merges; I've done it several times. Git will find the right branch where things went wrong, and then finds the commit on that branch without problems. Erik