Re: bug: `git pull --rebase` breaks in the presence of pushurls

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Dec 11, 2025, 15:54 UTC
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:

Show 8 quoted lines

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