<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 22, 2016 at 3:40 PM, Daniel Sanders via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do you have an example in mind? I'd expect them to rely on each 'master' being<br>
an improvement on 'master^'. I wouldn't expect them to be interested in how<br>
'master^' became 'master'.<br></blockquote><div><br></div><div>I would love it if each master commit was an improvement on the previous commit, or at last was virtually guaranteed to be not broken. It's most annoying that the existing LLVM history has a lot of examples of commits being reversed by a later commit.</div><div><br></div><div>The ease in git of branching -- and more importantly rebasing the branch on a later state of master -- means that you can run buildbots for all the different platforms on each pull request BEFORE merging it to master.</div><div><br></div><div>If buildbots are not fast enough to test every change (let alone repeatedly) then you can keep a pristine "master" head and a "proposed master" head that might have several pull requests added onto it sequentially. Then have the buildbots test the "proposed master" and if it passes then fast-forward advance the "master" head to the current "proposed master" head. Then merge the next batch of pull requests onto "proposed master", rinse and repeat.</div><div><br></div><div>If a "proposed master" fails and it has more than one pull request in it, then you can bisect it to find the bad pull request, throw it out, and try again without it.</div><div><br></div></div></div></div>