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:
> 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.
> 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
>> 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 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
>> email@example.com <mailto:firstname.lastname@example.org>
> devel mailing list
devel mailing list