Re: [PATCH 1/2] builtin/rebase.c: Emit warning when rebasing without a forkpoint

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 2, 2023, 22:36 UTC
Message-ID: <xmqqo7ikkxrq.fsf@gitster.g>
In-Reply-To: <fa702b47-ae29-4299-9226-4920620b9fff@opperschaap.net>

Wesley <wesleys@opperschaap.net> writes:

Show 12 quoted lines

> On 9/1/23 14:10, Junio C Hamano wrote:
>> Wesley <wesleys@opperschaap.net> writes:
>> 
>>> The quirk is this: --fork-point looks at the reflog and reflog is
>>> local. Meaning, having an remote upstream branch will make
>>> --fork-point a noop. Only where you have an upstream which is local
>>> and your reflog has seen dropped commits it does something.
>> Why do you lack reflog on your remote-tracking branches in the first
>> place?
>
> I do not know? I tested with a bare repo and two clones. And I also
> tested it with just a remote upstream in another branch.

IIRC, a non-bare repository (i.e. with working tree) should get core.logallrefupdates set to true by default, so all your refs, not just local and remote-tracking branches, should have records.

> I haven't force pushed anything btw, maybe that could explain things?

If your "remote" is never force-pushed, then the movements of refs at the remote (which you will observe whenever you fetch from it) will always fast-forward, and the remote-tracking branches in your local repository that keeps track of the movement will also record the fast-forwarding movement in the reflog. But then there is no need for the fork-point heurisitics to trigger, and even if it triggered the heuristics would not change the outcome, when rebasing against such a remote branch, as their tip will always a decendant of all commits that ever sat at the tip of that remote branch.