I've poked at the source code but haven't found exactly what causes the issue --- but if you do a 'git pull --rebase' or 'git rebase' onto a tracking branch that has previously pointed to a commit that the rebasing branch includes, the rebase will be a noop. In practice I've hit this a few times lately when splitting a topic branch into two branches after the fact. Here is a short repro: ``` git init touch file1 git add file1 git commit -a -m "first commit" touch file2 git add file2 git commit -a -m "second commit" touch file3 git add file3 git commit -a -m "third commit" git checkout -b branch git branch --set-upstream-to=master git checkout master git reset --hard 'HEAD^1' touch file2.5 git add file2.5 git commit -a -m "second-and-a-half commit" git --no-pager log --oneline --all --graph #rm .git/logs/refs/heads/master git checkout branch git pull -v --rebase git --no-pager log --oneline --all --graph ``` This outputs, * 58432a7 (branch) third commit | * 0e4f775 (HEAD -> master) second-and-a-half commit |/ * 37b2e3f second commit * 5e9f0b7 first commit ... Successfully rebased and updated refs/heads/branch. * 0e4f775 (HEAD -> branch, master) second-and-a-half commit * 37b2e3f second commit * 5e9f0b7 first commit showing that "third commit" is lost. If you execute the "rm ..." line, then the sequence works as expected, and the final state is, Successfully rebased and updated refs/heads/branch. * b636309 (HEAD -> branch) third commit * 410a5dc (master) second-and-a-half commit * 41981d0 second commit * 286398d first commit My best guess is that there's something odd happening in get_fork_point(). Cheers, Andrew
