From: Phillip Wood <phillip.wood123@gmail.com>
Date: Thu, 11 Dec 2025 15:54:33 GMT
Subject: Re: bug: `git pull --rebase` breaks in the presence of pushurls
Message-ID: <3a6f39cf-b35e-461f-84a7-85e6e7376d21@gmail.com>
In-Reply-To: <20251211053504.8758-1-jayatheerthkulkarni2005@gmail.com>

On 11/12/2025 05:35, K Jayatheerth wrote:
> I’m trying to make sure I fully understand where the fork-point behavior is coming from.
> I'm assuming get_rebase_fork_point() and get_rebase_newbase_and_upstream() are responsible.
> 
> And when we talk about the “fork-point heuristic” here,
> we mean the logic that uses the reflog of the upstream branch
> to detect whether the user has previously rebased or reset,
> and uses that information to choose a
> different merge-base than the raw merge-base HEAD upstream, correct?

Almost, it uses the reflog of the upstream branch to find the most 
recent entry that is a descendant of the local branch. It then uses that 
commit to limit the range of commits that get rebased in case the 
upstream branch has been reset or rewritten. There is a diagram in the 
documentation [1] which might help.

Thanks

Phillip

[1] https://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode

> Just checking that I’m following correctly
> before thinking about possible approaches.