Idempotent git rebase fails with spurious conflicts?

Question

My git repository has ~2,000 commits. For educational purposes, I have been playing around with git rebase -i.

When I type git rebase -i first-commit (where first-commit is a tag for the initial commit to the repo) and change nothing at all (i.e. leave all pick <hash> untouched), git starts replaying my history, but fails on dozens of commits citing conflicts. What would cause this? Why does it not simply replay my entire history?

Answer 1

I tried recreating it with an open source project, and got similar results, conflicts reported when rebasing on top of first commit using rebase interactive.

I ran it a second time and noticed it was happening at the same commit.

git clone git://git.lttng.org/lttng-tools.git
git tag first-commit fac6795
git rebase -i first-commit

Could not apply e4baff1... listing and activation of loglevel by number
git rebase --abort

It seems the conflict was happening close to a merge point:

* 843f5df (HEAD, tag: new-tag) API change for lttng_destroy_session prototype
*   90192ee Merge branch 'master'
|\  
| * 4dbd54a update loglevel printout
| * e4baff1 listing and activation of loglevel by number
* | 76d45b4 Add support for UST enable all tracepoints
* | 6181537 Cleanup lttng enable event command
|/  
* 13dce3b loglevels: allow enable/disable
* 81afa34 Add loglevel to event list
* 57ab763 ABIs now support 256 char event names

running the rebase again with the option -p was successful though:

-p, --preserve-merges
           Instead of ignoring merges, try to recreate them.

           This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a
           good idea unless you know what you are doing (see BUGS below).

git rebase will change the history to be more linear. Since there are merges in the history, they will have to be resolved if there are conflicts when the merge point is flattened out.