W3C home > Mailing lists > Public > public-webrtc-editors@w3.org > November 2015

Re: Rebasing finished pull requests

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 25 Nov 2015 20:11:44 +0100
To: public-webrtc-editors@w3.org
Message-ID: <565607F0.9090501@alvestrand.no>
On 11/25/2015 05:39 PM, Dominique Hazael-Massieux wrote:
> On 25/11/2015 17:30, Harald Alvestrand wrote:
>> I thought you could only rebase when you had write access to the
>> *source* repo (the one the original PR is merging from)?
> That is correct if you want to update the PR itself [I've been meaning
> to propose a way around that limitation in github, but that's for
> another thread].
> But in this case, what we want is to merge the PR, so updating the PR
> itself is no longer useful (we assume it has been reviewed and agreed
> upon). In that case, the editors can:
> * fetch the content of the PR branch
> * rebase it locally
> * merge it onto master

And then close the PR, which will give it status "closed" rather than
"merged" - in this case, it's extremely important to make a comment in
the PR saying that the PR was actually merged not closed.

> To fetch a remote PR, I have this following alias in my global git
> config (~/.gitconfig in my setup):
> [alias]
>         pr = !git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && :
> once that is configured, "git pr XXX" will fetch the content of the PR
> #XXX and make it available as a local branch named pr/XXX; using that
> alias is obviously not required, but it's probably a useful shortcut.
> So in more details, to rebase and merge PR #XXX (assuming master is up
> to date):
> * git pr XXX
> * git checkout pr/XXX
> * git rebase master
> [git add / git rebase --continue as needed]
> * git checkout master
> * git merge pr/XXX
> * git push origin master
> (off the top of my head)
> Dom

Surveillance is pervasive. Go Dark.
Received on Wednesday, 25 November 2015 19:12:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:03 UTC