It is not fast forward because your updated branch can no longer be reached by moving forward starting with where it was originally (which is where the remote still is). Git commits are immutable, so an entirely new set of commits is made when you rebase, containing the same change sets your original ones did:
master & origin/master feature
| |
v v
M -- N -- O -- P -- A' -- B' -- C'
\
A -- B -- C
^
|
origin/feature
This diagram should explain pretty clearly why you can't get from origin/feature
to feature
through a fast forward.
You can solve this in two ways. If you have the permissions set up, you can do a force-push. This is the easiest standard way to handle the situation. On egit, you do
- Team -> Push Branch
- Select "Force overwrite..."
(from EGit on Eclipse: How to git push --force?)
Another alternative would be to merge master into your branch instead of doing a rebase. This is not as clean history-wise, but it would replace your copied commits with a single merge commit, fixing your fast forwarding problem. The graph would look like this:
master & origin/master
|
v
M -- N -- O -- P --
\ \
A -- B -- C -- D
^ ^
| |
| feature
origin/feature
As you can see, feature
will be at a merge commit that is fast-forwardable from origin/feature
.
An even more complicated way would be to go on the server, reset feature
to master
, and then push from the client again. This is not a good idea in general, but it would guarantee that the push would be fast-forward:
# On the server:
git checkout feature
git reset --hard master