4

Yesterday we had this very strange situation with git:

  1. We created a feature branch as we always do. Then, somebody would work for some days on that feature branch.

  2. In the meantime, something important happened on the master branch. These changes were needed by the feature branch, too.

  3. Therefore, we merged the master branch into the feature branch (no rebase because our feature branches are usually immediately pushed to remote as we need to collaborate on a feature). This merge was only done locally and not yet pushed to remote.

  4. Work on the feature branch continued

  5. With the merge from master + the continued work the local feature branch new_feature was now ahead of origin/new_feature by 40 commits

  6. Now we wanted to push these 40 commits to the remote feature branch. First we do a git pull --rebase as we always do before we push because somebody else might have pushed some commits before us.

  7. Now we experience tons and tons of conflicts. We decide it's not worth fixing 40 commits and do a git rebase --abort. Then we try a git pull --no-rebase. We get: "Already up-to-date" - Strange

  8. Since git status does not tell us that our local branch and the remote branch have diverged, we try git push

  9. Unexpectedly, git push worked. We would get a rejected if we tried to push to a remote branch that has changed since we last pulled. So obviously remote hasn't changed but git pull --rebase did something strange.

So what's strange about this is that

  1. git pull --rebase did not immediately return "Already up-to-date" and

  2. git pull --rebase reported a ton of conflicts where really none should exit (the reported conflicts had nothing to do with the stuff that was worked on on the feature branch)

What could cause such a situation?

Robin Green
  • 32,079
  • 16
  • 104
  • 187

2 Answers2

2

I doupt you would get your expected result even if you have enabled rerere or if you would solve all the 40 conflicts. The problem is: You do a rebase but you want to commit a merge! By calling "git pull --rebase", git would perform a "git rebase origin/featureXY" (assuming your feature branch was called featureXY). Also if there are no changes on origin you perform a rebase on your current branch to the state of the origin branch. And git performs as always when you perform a rebase on a merge commit. It resolves every merges and creates a flat history. That means, every commit of the master that was previously merged into the branch will be applied on your branch. The result would be a straight history without any merge commit.

Conclusion: Avoid mixing rebase and merge! In your workflow it is inevitable to push a merge directly or you cannot continue using pull-rebase.

cornz
  • 641
  • 4
  • 18
1

Unfortunately, a rebase after a git merge will cause this, unless you previously had enabled git rerere. See git rebase after previous git merge

Community
  • 1
  • 1
Robin Green
  • 32,079
  • 16
  • 104
  • 187
  • But the real problem is that he do not want to rebase his merge commit at all... He just want to keep the merge as it is and make sure that he has all changes that were done on origin. Of cause that is a workflow problem and is not supported at all. – cornz Oct 06 '14 at 07:50