Merging rebasing strategy to align code based with stable releases

[anand agarwal]

Hi All,

We are developing custom browser for iOS/Android based on open source chromium. 

For iOS We took stable chromium version 87.0.4280.77 as base code and made our custom changes over it.

As we know chromium has launched stable 91.0.4472.80 version , so due to security reason we want to migrate our code to this stable version.  We thought to do rebase our code base with stable 91.0.4472.80 version, but facing many conflicts even in the files not changed by us. Going forward chromium has to plan to make stable releases in each and every four weeks, so we would want to align our code base with stable releases. Could you please suggest what should be merging/rebasing strategy we should follow to avoid potential conflicts and quickly move to latest stable versions of code base.

Regards,
Anand

[Yngve N. Pettersen]

Hi,

It sounds like you are rebasing more commits than you actually need to rebase.

First, just to be on the safe side, make sure your branch of custom changes does not contain any upstream cherry-picks mixed in with  your custom changes. If it does, then you need to do an interactive rebase to shuffle them down before your custom changes.

Then you:

1) create a new branch from the tip of your custom changes, e.g. my_new_version (If you need to do an interactive reshuffling-rebase, you do this before that rebase)

2) start the rebase with the command "git rebase --onto <new_chromium_upstream> <old_chromium_upstream> my_new_version

<old_chromium_upstream> is the last upstream commit before your first custom change on the 87.0.4280.77 Chromium branch

<new_chromium_upstream> is the most recent commit on the 91.0.4472.80 Chromium branch you are rebasing to.

This will rebase all your custom commits on top of the new upstream.

You will still see a lot of merge conflicts, but they should all be in files you have modified.

In some cases the conflicts in a file may be so large that it will probably be better to discard the old custom change, and reimplement it. In such cases it will frequently be better to just add a post-rebase task for it, and proceed with the rebase without the old change. Then, after the rebase is complete, you can reimplement it at leisure.

-- 
Sincerely,

Yngve N. Pettersen

Vivaldi Technologies AS

[anand agarwal]

Hi Pettersen,

Thanks for quick help and practical solution for this problem. Just to summarise,  in order to migrate to future stable release, we need to keep track of followings:

1. <old chromium upstream> which will be updated every time we move any next stable/beta releases.

2. <new_chromium_upstream> : That we can easily get it: this is version on which we want to rebase.

3. Commit id of tip of our custom changes (It should have been interactively rebased to shuffle down any upstream cherri pics).

I will use this strategy and update here about my observations. 

Regards,

Anand