Re: Bug with git merge-base and a packed ref

From: Jeff King <peff@peff.net>
Date: Oct 12, 2016, 16:32 UTC
Message-ID: <20161012163209.oadmm7xsmm7oeumr@sigill.intra.peff.net>
In-Reply-To: <20161012103716.GA31533@ucw.cz>

On Wed, Oct 12, 2016 at 12:37:16PM +0200, Stepan Kasal wrote:

Show 28 quoted lines

> 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