Thank you, Roland! It will be a great help for the other maintainers.
Atgeirr Den 24. sep. 2013 kl. 00:49 skrev Roland Kaufmann: > On 2013-09-23 03:12, Arne Morten Kvarving wrote: >> @rolk can push [build system changes] directly, once they have been >> reviewed and merged elsewhere > > But I won't :-) > > (If anyone is interested in how I did the CMake rollups, they can read a > write-up at <http://rolk.github.io/2013/09/23/build-system-sync/>. I > suspect there is an easier way with `git subtree split` though). > > On 2013-09-23 13:28, Arne Morten Kvarving wrote: >> i prefer squashed pulls. ... iow; mainline should not carry broken >> ... >> during the review process you push fixes as separate commits. they >> are reviewed. they are ack'd. then it's squashed up. only then is it >> pulled into mainline. > > I do have to say that I disagree with this view. I *do* agree that during > review we could add revisions with --fixup to ease the reviewing and then > squash *those* into their respective targets before merging. > > However, I don't think squashing the entire pull request into one when > merging necessarily is a good idea. `git blame` loose much value if the > commit is refers to is an entire pull request instead of a tiny revision, > `git bisect` likewise. > > On 2013-09-23 13:43, Andreas Lauser wrote: >> BTW: does anyone know if git bisect can be instructed to only bisect >> mergepoints? At least in principle, these should always compile... > > Just a quick comment here: If the build is broken, you can > return the magic value 125 from the script that you `git bisect run` and that > particular commit will be skipped (i.e. neither good nor bad). > > -- > Roland. > > _______________________________________________ > Opm mailing list > [email protected] > http://www.opm-project.org/mailman/listinfo/opm _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
