Wesley <wesleys@xxxxxxxxxxxxxxx> writes: > On 9/1/23 14:10, Junio C Hamano wrote: >> Wesley <wesleys@xxxxxxxxxxxxxxx> 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.
