Question

I have a little situation here. I rebased a dev branch, and tried to push it, but it was rejected (non-fast-forward)… Since I don’t know why, I come to you…

What I did:

git checkout dev
git rebase G
# Here, I had to manually merge some files

# Result (in gitk) was :
#       A---B---C remote/dev   A'---B'---C' dev
#      /                      /
# D---E---F------------------G---H remote/master

git push remote dev

Any idea why my push is “non-fast-forward” and thus rejected ?

Answer 1

It’s not fast-forward, because you did a rebase. rebase takes a bunch of commits and creates new commits from them (possibly in a different location in the commit DAG). Please make sure that you understand all the implications of running git rebase before actually doing so. Not being able to fast-forward is one of these implications.

Rebasing published history is generally considered a bad idea. If you really must rebase your branch and push it, pass the -f flag to git push, or prepend your refspec with a + (git push remote +dev).

Other people who have cloned your repository and worked an that branch will have to do the same rebase, or you will merge old history the next time you merge from one of your contributors.

---

Elaborating on fast-forward:

From your graph this is easily visible. Fast-forward basically only ever appends commits to history. Each commit is uniquely identified by its commit hash. The commit hash gets computed over the commit contents as well as the history of the commit. This means that commits with different ancestors/parents are going to have a different hash by definition.

If you take a number of commits and plug them to a different location in the DAG they will describe a different history and will get a new commit hash (commit times were also updated, but that’s not the point here). It’s therefore not possible to fast-forward because it’s not append-only anymore. Additionally you will be unable to access the old commits (without resorting to the reflog) after rebasing and pushing the result.

Another way to think about this: your push will not append commits to the old (remote/dev) branch, but append the commits elsewhere (commit G).