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
