missing commits after git rebase

Question

A-B-C  Master
 \D-E  Feature

After executing a rebase command git checkout feature -> git rebase master all my commits from feature branch disappears so I have A-B-C commits. feature branch looks like master after rebasing. Also rebasing doesn't give any error but it doesn't show 'commits are replayed' message which I think usually it shows during rebasing. Do you know what could have caused this behaviour?

Once I've noticed my commits disappeared I ran the following command to find the missing code in git history: git rev-list --all | xargs git grep expression This command returned a commit hash but this hash was not present when I run git log (because of rebase). If I do git reset --hard missing-hash I can see the original (correct) feature code again. Running rebase master recreates same problem again.

EDIT: I've just noticed I have some extra commits like WIP on commit-message and index on commit-message when I do git reset --hard missing-hash Can it be related with git stash / git stash apply

Answer 1

Just so were on the same page about how rebases work. In your example, git is basically trying to add and D and E after C one by one. The rebase commits on D & E will not be the originals, instead they will be clones with new hashes. The original will still exist, but will simply be dangling with no branch referencing them (garbage collection will delete them eventually). After a rebase, you can see the "original" version of the rebased commits by looking at git log ORIG_HEAD

However, exceptions can take place in this process. Git will intelligently skip any commits that are already in the "base" (master, in this case) - this can happen a branch gets merged, reverted, then remerged.

It will also skip any commits if it finds that the commits being added to the base identically match, in their content - commits that are already in the history - even if the hashes are different - this can happen if a branch is merged, rebase, then merged again.

I suspect one of a few situations.

1. Your feature branch may have already been merged into master.
2. Your feature branch already matches master.

1) git branch --contains feature

This will list all branches which contain your feature branch in their history. If master is in that list, then your branch is already merged. Nothing to do here.

Theres a few reasons this might not seem right though.

One reason is that you may not see your changes in the current master code. This could be for a few reasons. If the branch had been previously merged into master, and then reverted, then the commits are already there, but negated - even if remerged those reverted commits will not return - you would need to revert the actual revert commit.

2) git checkout feature; git rebase --keep-empty feature

The --keep-empty will force git to keep your commits even if they don't contain any "new" content or changes. This isn't a fix or workaround, but if you see these commits in your history after doing this - then it means your commits arent being lost. They are getting skipped intentionally. You can decide for yourself if you want to keep the empty ones.

If this is the case, then I would look to see if this branch has been merged in the past. It may have been merged as part of a different branch for example. Maybe Bob thought he needed your work from the feature branch in his bobs_feature branch - his branch made it to master before yours and now your branch is basically irrelevant. Another case might be that it was merged in the past into master, and then reverted. The answer here is to revert the revert commit itself - sort of like hitting redo after hitting an undo.