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
