RE: Using GitHub's merge button

Is our working guidance to avoid rebasing in the branch where the Pull Request originates?  I know the merge flow creates a branch for this, but have also had folks advise me to periodically rebase to stay on top of merge conflicts.

The modified flow from Mark below seems much like our current manual process, right?

Jerry

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Thursday, May 12, 2016 10:29 AM
To: David Dorwin <ddorwin@google.com>
Cc: Jerry Smith (IEP) <jdsmith@microsoft.com>; Matt Wolenetz <wolenetz@google.com>; public-html-media@w3.org; Philippe Le Hégaret <plh@w3.org>
Subject: Re: Using GitHub's merge button



On Thu, May 12, 2016 at 10:13 AM, David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>> wrote:
Currently, our process [1] is to manually squash and commit pull requests. This was discussed in the thread ending in [2]

As mentioned in the review of EME #165, it appears GitHub now supports squashing via the big green button [3], and HTML now allows use of the button [4]. I believe we can do the same thing.

As discussed in #165, there are still some details to figure out:

  *   We need Philippe or someone else with admin access to verify both types are allowed in the GitHub repo settings [5].
  *   Rebasing/merging: Rebasing might cause problems for history. (See the last paragraph below.) We might instead need to use merges when updating PRs. Either way, the squashed commit should be a single commit.

     *   We might need to experiment here.
​Can GitHub really squash the commits if there are merges in there ? That seems like a process that could result in conflicts.

We may need to do the following:
(1) Create a new branch off the PR branch
(2) Rebase in that new branch, force push
(3) Make a new PR from the new branch and merge this, with squashing
(4) Decline the original PR

Each change would then have two PRs, the original one which documents the history and discussion and a rebased one which has the clean changes to the then-latest specification, still in separate commits.

...Mark

​




     *   As an aside, it's helpful to the reviewer to delay rebasing/merging until the end.

The process will be approximately:

  *   Push the green "Merge pull request" button.
  *   Review and clean up the commit message.
  *   Select "Confirm squash and merge"

Using the button should pretty much eliminate forced pushes, which can cause diffs with comments to be lost as mentioned in #165.


[1] https://github.com/w3c/encrypted-media/blob/gh-pages/TEAM.md

[2] https://lists.w3.org/Archives/Public/public-html-media/2015Nov/0011.html

[3] https://github.com/blog/2141-squash-your-commits

[4] https://github.com/whatwg/html/blob/master/TEAM.md

[5] https://help.github.com/articles/configuring-pull-request-merge-squashing/