git pull --rebase differs in behavior from git fetch + git rebase

[Joshua Jensen <jjensen@workspacewhiz.com>]

  I have a case where 'git pull --rebase' does not do the Right Thing 
(according to me).

If I run 'git rebase origin/master', that rebase does the right thing, 
perfectly reapplying my *single* commit on top of the upstream.

'git pull --rebase' ends up reapplying a bunch of much earlier commits 
and ends up with a conflict.

The documentation for git pull --rebase states: "Instead of a merge, 
perform a rebase after fetching. If there is a remote ref for the 
upstream branch, and this branch was rebased since last fetched, the 
rebase uses that information to avoid rebasing non-local changes."  I do 
not understand

I'm studying the git-pull script right now, but I have to admit this is 
beyond me.  I'm sure if I stare hard enough, I'll get it.

I mistakenly have assumed 'git pull' = 'git fetch; git merge' and that 
'git pull --rebase' = 'git fetch; git rebase'.  Does anyone want to 
clarify what is really going on?  Unfortunately, I can't publish the 
repository in question.

Thanks!

Josh