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

[Sven Panne]

2015-10-14 15:15 GMT+02:00 Erik Hesselink <hesselink at gmail.com>:

> This is getting a bit off topic, but anyway: I'm not even sure about
> that. What if your tools finds a regression, and you want to revert
> it. If it's part of a big rebased branch, this is tricky because the
> whole feature might depend on it. If it's a merge, though, you can
> just revert the merge.
>

OK, now we're really off-topic, but anyway: But when you revert the merge
(which brought in lots of commits at once), you still have no idea which
individual commit caused the regression. Perhaps there isn't even a
regression on your branch at all, only after the merge. Been there, done
that... :-P When you have a multi-million line project with hundreds of
people working on it, your bots can't keep up with the constant stream of
commits (so they typically batch things, doing more detailed runs later
when there is time, if any), and you really have to rely on some kind of
continuos integration, things get really complicated. So I understand the
policy of taking one problem out of the way, namely non-linear history.
That's at least what I've experienced, but your mileage may vary, of course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151014/b4ed97fd/attachment.html>