1

I'm on a feature branch, and I've just done a succesful rebase (Team > rebase > master) so my branch doesnt get too far from master.

Now in the Eclipse git history, I can see the 5 commits of my branch are on top of master, which is the expected result.

But there are some indicators next to the project name, saying [up-arrow] 7 [down-arrow] 5, and when I try to push my branch on the remote branch, it says : "rejected non-fast-forward" (I'm working alone on this remote repository and I have only one git client which is Eclipse egit).

Could someone tell me how I can be "non-fast-forward" after a rebase ? And what should I do from now ? "rebase" again ? "pull" ? "merge" ?

Tristan
  • 8,733
  • 7
  • 48
  • 96

1 Answers1

2

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

  1. Team -> Push Branch
  2. 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
Mad Physicist
  • 107,652
  • 25
  • 181
  • 264
  • Ok, this makes sense. I guess git push with "force" option would have been my best move. Now, using old habits, I've done "git pull" then "git push", what is wrong where now ? (on my local history, it shows the same way as before). – Tristan Jul 13 '18 at 11:20
  • @Tristan. In that case feel free to select my answer. – Mad Physicist Jul 13 '18 at 13:30
  • Sure if you can add this precision (what is wrong after doing a pull push instead of a forced push ?). – Tristan Jul 14 '18 at 13:51