From: Sergey Organov <sorganov@gmail.com>
To: Erik Cervin Edin <erik@cervined.in>
Cc: "Cem Gündoğdu" <cscallsign@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: Git rebase no longer defaults to upstream after force push
Date: Wed, 19 Apr 2023 20:03:58 +0300 [thread overview]
Message-ID: <87ttxbztvl.fsf@osv.gnss.ru> (raw)
In-Reply-To: <CA+JQ7M_XP6fjdut10ry9db9M3pEhp3-+zToJ93gnbHo-4p_8uQ@mail.gmail.com> (Erik Cervin Edin's message of "Wed, 19 Apr 2023 17:43:10 +0200")
Erik Cervin Edin <erik@cervined.in> writes:
> 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
next prev parent reply other threads:[~2023-04-19 17:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 9:17 Git rebase no longer defaults to upstream after force push Erik Cervin Edin
2023-04-18 14:01 ` Phillip Wood
2023-04-18 15:54 ` Cem Gündoğdu
2023-04-19 15:43 ` Erik Cervin Edin
2023-04-19 17:03 ` Sergey Organov [this message]
2023-04-19 0:06 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttxbztvl.fsf@osv.gnss.ru \
--to=sorganov@gmail.com \
--cc=cscallsign@gmail.com \
--cc=erik@cervined.in \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox