Re: Git rebase no longer defaults to upstream after force push

From: Sergey Organov <sorganov@gmail.com>
Date: Apr 19, 2023, 17:03 UTC
Message-ID: <87ttxbztvl.fsf@osv.gnss.ru>
In-Reply-To: <CA+JQ7M_XP6fjdut10ry9db9M3pEhp3-+zToJ93gnbHo-4p_8uQ@mail.gmail.com>

Erik Cervin Edin <erik@cervined.in> writes:

Show 20 quoted lines

> On Tue, Apr 18, 2023 at 5:54 PM Cem Gündoğdu <cscallsign@gmail.com> 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