<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-10-14 15:15 GMT+02:00 Erik Hesselink <span dir="ltr"><<a href="mailto:hesselink@gmail.com" target="_blank">hesselink@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">This is getting a bit off topic, but anyway: I'm not even sure about</span><br></div></div>
that. What if your tools finds a regression, and you want to revert<br>
it. If it's part of a big rebased branch, this is tricky because the<br>
whole feature might depend on it. If it's a merge, though, you can<br>
just revert the merge.<br></blockquote><div></div></div><br></div><div class="gmail_extra">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.</div></div>