RE: Using GitHub's merge button

We all create a branch for each PR so that subsequent commits are isolated to the issue they are working.  Is it okay to rebase in these (git rebase gh-pages)?

Jerry

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


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.

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.
>
> 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.
>
>           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.ht

> ml
>
>     [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/

>

Received on Friday, 13 May 2016 00:26:19 UTC