The last line is wrong. repo is actually trying to say that there are published commits that its cowardly refusing to rebase for you.
When you get into this condition, I guess you really have 3 options:
- detach HEAD and switch to the manifest revision. This makes you match the trunk, but removes the change you still have pending for review.
repo sync -d frameworks/base
- merge the manifest revision in. This creates a potentially unnecessary merge commit. A future repo upload would upload it for code review. If submitted, its an unnecessary point in the project history. Doing this too much is going to create a very cluttered project history that is hard to follow.
(cd frameworks/base; git merge m/master)
- rebase onto the manifest revision. This changes the commit SHA-1 of the change you already published for review. It also may cause line numbers to shift around in files, if the file was modified by both your change and upstream. If you try to address reviewer comments, you may not be looking at the same thing as the reviewer. If the change gets submitted, you now have a different name for that same change, and may get a repo sync failure trying to merge your own code with itself.
(cd frameworks/base; git rebase m/master)
You could then upload replace the patch set onto the existing change, but that gets old fast.
Doing any of these options by default in repo sync feels wrong to me, as every single one has downsides. It depends on context and what you are willing to tolerate.