On 24/09/13 10:48, Andreas Lauser wrote:
Hi!
On Tuesday 24 September 2013 09:35:29 Arne Morten Kvarving wrote:
On 24/09/13 00:49, Roland Kaufmann wrote:
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).
I suppose I will continue to use my own script:
for COMMIT in $LIST_OF_HASHES; do
cd $SRC_DIR/opm-core
rm *.patch
git format-patch $COMMIT~1..$COMMIT
cd $SRC_DIR/opm-$OTHER_MODULE
git am ../opm-core/*.patch
done
this is probably not as bullet proof as Roland's way, but my simple mind
understands it more easily ;)
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.
i never meant that we'd squash the entire pull up, sorry if that was the
impression. a pull should, as requested, be split into logic commits. as
long as it doesn't break at any of them. i meant you use fixup to adress
comments on the individual commits.
the problem with --fixup during review is that all consecutive patches will get
a different hash and github will thus treat them as if they were entirely new.
(which makes reviews harder, IMHO.) The best methodology is probably the
following procedure:
- create a PR
- while it is reviewed, only add patches to it at the end
- _after _the review (indicated by a maintainer):
- run `git fetch origin; git rebase origin/master` to make the Big Green
Button (TM) re-appear. (if it disappeared in the meantime.)
- if the patches are not yet split in a completely meaningful way, use
`git rebase -i origin/master` to reorder and squash
- force push the branch to the PR's repo on github (i.e., use `git push -f`)
- after that, a maintainer presses The Big Green Button
good thing we all agree :)
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm