Erik Cervin Edin <erik@xxxxxxxxxxx> writes: > On Tue, Apr 18, 2023 at 5:54 PM Cem Gündoğdu <cscallsign@xxxxxxxxx> wrote: >> > If <upstream> is not specified, [...] and the --fork-point option is assumed. >> >> The --fork-point option does this: >> >> > Use reflog to find a better common ancestor between <upstream> and >> > <branch> when calculating which commits have been introduced by >> > <branch>. >> >> Since the parent of a is still in the reflog of origin/a, it is not >> being rebased (the rationale being that the commit *was* in origin/a >> at some point). If you want to disable this behavior, add >> --no-fork-point option: > > Yes. That's it, thank you for pointing out --fork-point. That's indeed > what's causing the unexpected behavior. > > Do you happen to know when such behavior is desirable? I'm tempted to > change the default to --no-fork-point but usually when something is > default there's a valid reason.. 🤔 $ git help merge-base has a thorough discussion of --fork-point that might be helpful. As far as I understand, it helps to DWYM when remote branch has been rewound, and causes nasty confusion when it fires unintentionally. -- Sergey
