Re: Using GitHub's merge button

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

>
>
> On 05/12/2016 05:25 PM, Jerry Smith (IEP) wrote:
>
>> We all create a branch for each PR so that subsequent commits are
>> isolated to the issue they are working.
>>
>
> Yes, of course.
>
>  Is it okay to rebase in these (git rebase gh-pages)?
>>
>
> Not sure what you mean here. In my proposal, the history of commits is
> maintained on the master branch and the gh-pages branch only contains the
> automatically generated draft, so no need to rebase anything there.
>
> Having said that, such change at the moment could be disruptive to you
> folks so I'd rather not touch the branches until you folks want me to
> squash btw. Just give me the word and I'll do it.


​We are treating gh-pages as our master branch (at the moment). We have no
branch called "master".

The problem with rebasing is that it messes up the history in the PR. I
think you need to merge from gh-pages into the PR branch to resolve
conflicts.

...Mark​



>
>
> Philippe
>
>
>
> 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/
>>>
>>>