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

[Erik Hesselink]

On 14 October 2015 at 11:51, Sven Panne <svenpanne at gmail.com> wrote:
>
> 2015-10-14 10:14 GMT+02:00 David Turner <dct25-561bs at mythic-beasts.com>:
>>
>> [...] 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