I agree: everything is working; everything is fine. I believe Howard simply asked because we almost always see PR's and merge commits from Gilles. Since this one didn't have a merge commit, he thought Gilles might have made a mistake and pushed to the wrong branch (or somesuch), and that these commits may have accidentally been pushed to master before they were ready. That's why he asked.
Looks like it was fully intentional this time -- soooo... moving on. :-) > On Dec 1, 2016, at 8:27 PM, r...@open-mpi.org wrote: > > Enough folks - we all have different methods of working, and despite all the > angst, it all seems to work. > > Gilles: there is nothing wrong with the master. It works fine. > > Let’s get back to doing something useful > > >> On Dec 1, 2016, at 5:15 PM, Gilles Gouaillardet <gil...@rist.or.jp> wrote: >> >> Paul, >> >> >> that is a fair point, and i do not mind *always* using the github merge >> button if this is what is best for most of us. >> >> >> by the way, what was the issue in the first place ? >> - broken master ? >> - a bunch of commits that did not break anything but that could have been >> pushed accidentally ? >> >> >> note this PR was a bunch of mostly unrelated commits, and hence there was >> not a real "cut line". >> >> my understanding is we allow ourselves this kind of flexibility with the >> master branch, plus the commits passed >> >> the CI testings so that is ok *to me* (let me emphasize to "to me" one more >> time, and this is not a strong opinion). >> >> plus our workflow is to cherry-pick from master and PR to the release >> branch(es) (vs gitflow and variants) so i do not >> >> see a strong need for artificial cut lines, nor a unique set of related >> commits per PR. >> >> >> Cheers, >> >> Gilles >> >> On 12/2/2016 9:41 AM, Paul Hargrove wrote: >>> >>> On Thu, Dec 1, 2016 at 4:25 PM, Gilles Gouaillardet <gil...@rist.or.jp> >>> wrote: >>> [...] >>> git checkout master >>> >>> git merge --ff-only topic/misc_fixes >>> >>> git push origin master >>> [...] >>> >>> >>> Gilles, >>> >>> You characterized the merge commit has having "close to zero added value" >>> to you - but in this instance it would have saved you and others a >>> non-trivial amount of time in email. >>> >>> Additionally, in projects I work on we value that merge commit as a "cut >>> line" if we ever need to revert an entire PR for some reason. Using >>> git-bisect such that one includes or excludes the entire PR is also a >>> justification for keeping the merge commit. So my opinion is that you >>> should have omitted "--ff-only" and entered a commit message that at least >>> identified the PR number. >>> >>> though this does not generate a git commit, github.com is smart enough to >>> figure this out and marks the PR as merged. >>> >>> >>> FWIW: "smart enough" is simply a detection that the last commit in the PR >>> has become an ancestor of the current HEAD. >>> >>> -Paul >>> >>> -- >>> Paul H. Hargrove phhargr...@lbl.gov >>> Computer Languages & Systems Software (CLaSS) Group >>> Computer Science Department Tel: +1-510-495-2352 >>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >>> >>> >>> _______________________________________________ >>> devel mailing list >>> >>> devel@lists.open-mpi.org >>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >> >> _______________________________________________ >> devel mailing list >> devel@lists.open-mpi.org >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
