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 >> <mailto: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 <http://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 >> <mailto: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 <mailto:devel@lists.open-mpi.org> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >> <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
