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

[Sven Panne]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/3b8de1ac/attachment.html>