- From: Philippe Le Hegaret <plh@w3.org>
- Date: Thu, 12 May 2016 17:50:01 -0700
- 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" <public-html-media@w3.org>
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. 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/ >>
Received on Friday, 13 May 2016 00:50:11 UTC