[Nexus 7 Android Development] fattire:
If I'm understanding you right, here's another way to do it...

Are you familiar with the "rebase" command? It does exactly what you're describing. It's probably better to rebase than to merge.

I'm not sure exactly what you're trying to do overall... it sounds like you're trying to have your own frameworks/base in github that you can keep in sync with cyanogenmod and at the same time make your own changes?

If so, another way to do it is this:

1. init the repo and repo sync as per the regular instructions.

2. Find the particular repositories you want to make your own copies of. You can find them all at github.com/cyanogenmod. Notice that frameworks/base is one of them. Then hit the "fork" button in the top right to make your own "working" copy in your account.

3. Modify your .repo/local_manifest.xml to remove the official version of frameworks/base and replace it with your own the next time you repo sync. The file would look something like this:

<?xml version="1.0" encoding="UTF-8"?>

<manifest>

<remote fetch="git://github.com/" name="gh" review="review.cyanogenmod.com" />

<remove-project name="CyanogenMod/android_frameworks_base" />

<project name="YourNameHere/android_frameworks_base" path="frameworks/base" remote="github" revision="jellybean" />

</manifest>

The local_manifest.xml file overrides the manifest.xml in .repo and allows you to add or remove git repositories or swap out official repositories with your own version(s).

4. Then repo sync and your unofficial copy on github will replace the official copy.

5. cd to frameworks/base and add a remote to point to the official version (for updating in the future) by typing git remote add upstream https://github.com/cyanogenmod/android_frameworks_base.git

5. Now make any changes you like. You can build to test, and create new commits and whatever.

6. Whenever you want to sync to upstream (official) , you can type: git fetch upstream, which grabs all the changes but doesn't apply it anywhere, then git rebase upstream/jellybean. This should update your jellybean branch to match the official upstream jellybean branch, and then apply all the commits you've made AFTER (or "on top of") the official changes. So you'll effectively be up-to-date with the upstream. If anthing has changed upstream that clashes with your changes, you'll be notified and have to do any changes to make those commits apply.

6. At any point you can just git push your changes back to your github account.

At some point, if the changes you've made are awesome enough to submit upstream, see the gerrit document on how to submit the commits you've made. Usually this is done on a new branch of the official repository, not w/ a new repository. But if you're just interested in making your own frameworks/base for your own purposes on github and don't expect to merge back to upstream any time soon, this seems like a good way to do it.

If you ARE planning on making changes that contribute back upstream, you might consider another method--

1. fork the project as described in step 2 above.

2. Now without doing any local_manifest.xml stuff, simply make a new branch with git branch somenewfeature.

3. Make any changes and new commits you like to this new branch until you get it working. git checkout branchname lets you switch between branches.

4. If you don't want to submit it to gerrit to be approved for upstream yet, set up a remote pointing to your fork and then push your changes up from your local "somenewfeature" branch -> the "jellybean" branch of your github fork. This will allow you to show your project to others, and they can try it out themselves.

5. Once everyone agrees it's "good enough" for inclusion into mainline CM10, you can follow the regular gerrit instructions to make a submission.

Or, if you don't intend to ever upload your changes, you can always use a local branch for testing and push it to your github's official "jellybean" branch or whatever.

Make sense? There are a million ways to keep your fork in sync and I'm not 100% sure what your goals are here, but those are just two options...