Re: Using GitHub's merge button

On Thu, May 12, 2016 at 5:10 PM, Philippe Le Hegaret <plh@w3.org> wrote:

>
> Ideally, here what I think the editors could use:
>
> - use a master branch for the respec version of the version and edits and
> PRs go against that branch.
> - set the master branch to have the web UI use squash instead of merge
> - use the gh-page branch to have the draft automatically generated into
> everytime there is a commit or a merge into the master branch.
>
> You avoid merge conflict on the generated draft like that.
>

​On the generated file, yes. But those conflicts are easy to resolve.​


> Philippe
>
> On 05/12/2016 05:05 PM, Jerry Smith (IEP) wrote:
>
>> 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.
>>
>
​That would be ideal, except that the force push needed after a rebase
obscures / destroys (not sure which) comment history in the PR.​

Everything I read about git workflows favors rebasing though ...


>
>> The modified flow from Mark below seems much like our current manual
>> process, right?
>>
>
​Yes, except that (i) the working branch used for the final merge is left
as a visible PR and (ii) github does the squash automatically.

...Mark


>> 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.
>>
>>           o 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
>>
>> ​
>>
>>           o 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/
>>
>>