Question

When I enter:

git rebase -i HEAD~3

Instead of getting the last 3 commits, I’m seeing the last 10.

For some reason , where N is the number i pass in , if 2 <= N <= 10 , I see 10 options. if N = 1, i just see the last commit.

This begs 2 questions:
1. Does anyone know why this is happening ?
2. Does anyone know how I can get N to be 3 ? There are a lot of conflicts that are coming up in the further out commits, and I don’t want to work against them.

For a bit of context:
I have a git “feature branch” that is just a patch to allow some legacy code to work on locally on Macs. it addresses a handful of issues on an ancient Drupal installation that is still in production. i’ve been patching that in to develop against locally, then rebasing it out for commits so it can tested on a staging environment. it’s worked fine… until just now.

Answer 1

The key to what you are seeing is the actual behavior of rebase along with the revision specifier ~.
I got this tree structure and the information on how ~ works from http://schacon.github.com/git/git-rev-parse.html#_specifying_revisions.

Following this history graph is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.:

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A

As the page I sourced indicates, ~ refers to Nth grandparent where the grandparent will be the first parent of any merge. If you were on a branch where HEAD->A and specified HEAD~3 as your revision that would point to G.

So rebase -i HEAD~3 would say you wanted to interactively rebase all commits from G to A ontop of G. That means you will see ALL the other commits as part of the rebase process, so instead of just D, B, and A, you will A-F and H-J in the rebase list. That would be 8 different commits listed vs. 3.