Rebasing chromium branches across the blink merge point

[Primiano Tucci]

It turns out that rebasing local chromium branches (created before the blink merge) after the blink merge point doesn't Just Work (TM) and ends up replaying the entire blink history on top of the branch, which is not really what you want.

Under the assumption that you are using a rebase workflow (i.e. you have N commits on top of some point of master), I think that the most effective way to update your branches is:

# only once to update the remote

$ git remote update (or git fetch)  

# For each branch

$ git rebase $(git merge-base branch_name origin/master) branch_name --onto origin/master

Which in human words should translate into "take all the commits between the previous state of master before the merge (i.e. the output of merge-base cmd) and the head of branch_name and replay them on top of the new origin/master (post merge point)"

Merge workflows might jus work (didn't try though, enough merges for today).

P.S. for blink branches, instead, refer to the Blink post-merge FAQs

Primiano

[Primiano Tucci]

+blink-dev

[Peter Kasting]

On Wed, Sep 23, 2015 at 4:46 PM, Primiano Tucci <prim...@chromium.org> wrote:

It turns out that rebasing local chromium branches (created before the blink merge) after the blink merge point doesn't Just Work (TM) and ends up replaying the entire blink history on top of the branch, which is not really what you want.

Under the assumption that you are using a rebase workflow (i.e. you have N commits on top of some point of master), I think that the most effective way to update your branches is:

# only once to update the remote

$ git remote update (or git fetch)  

# For each branch

$ git rebase $(git merge-base branch_name origin/master) branch_name --onto origin/master

Which in human words should translate into "take all the commits between the previous state of master before the merge (i.e. the output of merge-base cmd) and the head of branch_name and replay them on top of the new origin/master (post merge point)"

Another way, if you've uploaded to Rietveld:

* Download your existing patch

* Make a new branch off the new origin/master point

* Apply your patch (resolving any conflicts)

* git cl issue <###> (to set this branch as associated with a particular Rietveld issue)

* Delete your old branch

You lose the local branch history this way but if you've gotten to the point of uploading the patch, that probably doesn't matter.

PK

[Matt Giuca]

FYI, a merge workflow Just Works™. It's hella slow (about 30--40 seconds per branch) but it works just as expected.

(Aside: I'm not sure exactly why a simple "git rebase" doesn't work here... it should just be finding all of your local changes against the common ancestor and then cherry-picking them onto the new HEAD; I'm not sure why the Blink merge breaks that. When I tried it, it just took a really long time -- minutes -- so I gave up and used Primiano's command instead.)

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Colin Blundell]

On Thu, Sep 24, 2015 at 10:18 AM Matt Giuca <mgi...@chromium.org> wrote:

FYI, a merge workflow Just Works™. It's hella slow (about 30--40 seconds per branch) but it works just as expected.

(Aside: I'm not sure exactly why a simple "git rebase" doesn't work here... it should just be finding all of your local changes against the common ancestor and then cherry-picking them onto the new HEAD; I'm not sure why the Blink merge breaks that. When I tried it, it just took a really long time -- minutes -- so I gave up and used Primiano's command instead.)

I think that's the thing -- and the only thing -- that Primiano's email is addressing. Not that it won't eventually work, but that it will take much much longer than you want.

[Peter Kasting]

On Thu, Sep 24, 2015 at 1:17 AM, Matt Giuca <mgi...@chromium.org> wrote:

(Aside: I'm not sure exactly why a simple "git rebase" doesn't work here... it should just be finding all of your local changes against the common ancestor and then cherry-picking them onto the new HEAD; I'm not sure why the Blink merge breaks that. When I tried it, it just took a really long time -- minutes -- so I gave up and used Primiano's command instead.)

I tried letting mine sit at the "First, rewinding head to replay your changes..." step for an hour or so and gave up at that point.  :P

PK 

[Torne (Richard Coles)]

If anyone is curious I know why this takes so long. It's not trying to replay all of webkit, and it will succeed if you wait long enough (though I'm not sure how long it will take - certainly much longer than an hour or two).

If you do "git rebase origin/master mybranch", then under the hood it eventually ends up executing the equivalent of "git rev-list --cherry-pick --right-only origin/master...mybranch", *not* "git rev-list origin/master..mybranch" (with only two dots) as you might expect. This means that instead of just finding all the commits on your branch that don't exist upstream, it *also* finds all the commits upstream that don't exist on your branch (i.e. all 180000 webkit changes), and then goes off to calculate the patch id of every single one of them, to see if any of your changes have been applied upstream already. This is a pretty expensive operation :)

The reason it does this is so that if one of your patches is applied upstream already, it can skip it instead of trying to reapply it on top of upstream, since if the affected files have been changed since then reapplying it might fail and generate conflicts.

By using Primiano's command, you avoid this performance cost (because using the merge base as the left arg here means that side of the symmetric difference is empty), but also give up the ability to recognise if your changes have already been landed. :)

--

[Anton Vayvod]

On Tue, Oct 6, 2015 at 4:17 PM, Torne (Richard Coles) <to...@chromium.org> wrote:

If anyone is curious I know why this takes so long. It's not trying to replay all of webkit, and it will succeed if you wait long enough (though I'm not sure how long it will take - certainly much longer than an hour or two).

IIRC for me it took only 49 minutes on my workstation.

 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.