I just recently blogged on this topic:
How do we keep this feature branch up to date? Merging the newest upstream commits is easy, but you want to avoid creating a merge commit, as that won’t be appreciated when pushed to upstream: you are then effectively re-committing upstream changes, and those upstream commits will get a new hash (as they get a new parent). This is especially important, as those merged commits would be reflected in your GitHub pull request when you push those updates to your personal GitHub feature branch (even if you do that after you issued the pull request.)
That’s why we need to rebase instead of merging:
git co devel #devel is ansible's HEAD aka "master" branch
git pull --rebase upstream devel
git co user-non-unique
git rebase devel
Both the rebase option and rebase command to git will keep your tree clean, and avoid having merge commits.
But keep in mind that those are your first commits (with which you issued your first pull request) that are being rebased, and which now have a new commit hash, which is different from the original hashes that are still in your remote github repo branch.
Now, pushing those updates out to your personal GitHub feature branch will fail here, as both branches differ: the local branch tree and the remote branch tree are “out of sync”, because of those different commit hashes. Git will tell you to first git pull --rebase, then push again, but this won’t be a simple fast-forward push, as your history got rewritten. Don’t do that!
The problem here is that you would again fetch your first changed commits as they were originally, and those will get merged on top of your local branch. Because of the out-of-sync state, this pull does not apply cleanly. You’ll get a broken history where your commits appear two times. When you push all of this to your GitHub feature branch, those changes will get reflected on the original pull request, which will get very, very ugly.
AFAIK, there is actually no totally clean solution to this. The best solution I found is to force push your local branch to your GitHub branch (actually forcing a non-fast-forward update):
As per git-push(1):
Update the origin repository’s remote branch with local branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository.
So don’t pull, just force push like this:
git push svg +user-non-unique
or:
git push svg user-non-unique --force
This will actually plainly overwrite your remote branch, with everything in your local branch. The commits which are in the remote stream (and caused the failure) will remain there, but will be dangling commits, which will eventually get deleted by git-gc(1). No big deal.
As I said, this is AFAICS the cleanest solution. The downside of this, is that your PR will be updated with those newest commits, which will get a later date, and could appear out of sync in the comment history of the PR. No big problem, but it could potentially be confusing.
