Bug: git pull --rebase rewinds without applying commits in special workflow.

["Andreas T.Auer" <andreas.t.auer_gtml_37453@ursus.ath.cx>]

Hi,

in our workflow commits can be removed from from the tip of the branch 
in the
central repo. After this git pull --rebase on the "client" side may "lose"
commits, because the rewinding takes place without an fast-forwarding.


$ git log --oneline master           # example repo with 3 commits
b52b381 c3
faf6bbe c2
2ad3897 c1

$ git push origin master             # let the remote be up-to-date

$ git push origin +master^^:master   # simulate removal on remote

$ git pull --no-rebase               # pull without rebase works fine
Already up-to-date.                  # master points still to c3

$ git pull --rebase --prune          # pull --rebase with pruning also works
Current branch master is up to date. # master points still to c3

$ git pull --rebase                  # git pull --rebase does part of 
its job
First, rewinding head to replay your work on top of it...

$ git log --oneline master           # commits c2 and c3 are "lost" on 
master
2ad3897 c1


The actual workflow is that the commits are removed in the post-receive
hook of the central repo and send to an automatic test. After this passes
the commit is sent to svn and the result is then put to the top of the
branch.In case of a failure, the user should still have his commits in
his repo, so he could amend it and send again.
Using -p with git pull is currently the workaround to this.

Regards
Andreas