On Wed, Oct 12, 2016 at 12:37:16PM +0200, Stepan Kasal wrote: > A reproducer would look like that > > # in repo1: > git checkout tmp > cd .. > git clone repo1 repo2 > cd repo1 > git rebase elsewhere tmp > cd ../repo2 > # edit > git commit -a -m 'Another commit' > git pull -r > > The last command performs something like > git rebase new-origin/tmp > instead of > git rebase --onto new-origin/tmp old-origin/tmp > > I'm using git version 2.10.1.windows.1 > > > I tried to debug the issue: > I found that the bug happens only at the very first pull after clone. > I was able to reproduce it with git-pull.sh > > The problem seems to be that command > git merge-base --fork-point refs/remotes/origin/tmp refs/heads/tmp > returns nothing, because the refs are packed. The --fork-point option looks in the reflog to notice that the upstream branch has been rebased. I don't think clone actually writes reflog entries, though, which would explain why it happens only on the first pull after clone. I suspect the necessary information _is_ there, though. When we update the tracking branch, the new reflog entry will show it going from sha1 X to sha1 Y. So my guess is that --fork-point is looking for the entry where it became "X" (which doesn't exist, because clone did not write it), but it _could_ find that we came from "X" in the very first reflog entry. That's all without looking at the code, though. I don't have time to examine it now, but maybe that can point somebody in the right direction. > Could you please fix merge-base so that it understands packed refs? I think the packed-refs thing is probably a red herring. If merge-base didn't understand packed refs, a huge chunk of git would be horribly broken. -Peff