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
just
cheers
--
A programmer had a problem. He thought to himself, "I know, I'll solve it with
threads!". has Now problems. two he
-- Davidlohr Bueso
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
