Re: git pull/rebase bug: when "onto" branch has rebasing branch's commits in reflog

> 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().