From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Alex Henrie <alexhenrie24@gmail.com>,
Phillip Wood <phillip.wood123@gmail.com>,
Son Luong Ngoc <sluongng@gmail.com>,
Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH 3/5] pull: handle conflicting rebase/merge options via last option wins
Date: Thu, 15 Jul 2021 12:46:35 -0500 [thread overview]
Message-ID: <60f0747b149eb_4b682084c@natae.notmuch> (raw)
In-Reply-To: <xmqq7dhrtrc2.fsf@gitster.g>
Junio C Hamano wrote:
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > --- a/Documentation/config/pull.txt
> > +++ b/Documentation/config/pull.txt
> > pull.rebase::
> > When true, rebase branches on top of the fetched branch, instead
> > of merging the default branch from the default remote when "git
> > pull" is run. See "branch.<name>.rebase" for setting this on a
> > - per-branch basis.
> > + per-branch basis. Incompatible with pull.ff.
>
> Likewise.
>
> I think it technically is OK to say "only ff update is allowed" or
> "ff update is allowed when able" while saying pull.rebase=yes.
>
> - For those who say ff=only, the actual value of pull.rebase would
> not matter (i.e. the integration immediately finishes by updating
> to what was obtained from the upstream because there is no new
> development on our own on top of theirs to either replay or
> merge).
>
> - For those who merely allow ff, an update may fast-forward even
> when pull.rebase is set to true (or any non-false value), while
> we'll replay our own development on top of theirs when their
> history is not descendent of ours.
>
> So I do not see need to declare these combinations "incompatible".
> But perhaps I am missing some subtle cases?
Doing such a thing would be wrong. As I already explained multiple
times, pull.rebase can be overriden by the command line. When doing
--merge we want to honor pull.ff, when we don't we want to ignore it.
Since both Elijah and Junio have muted me, and they keep making these
mistakes, can anybody else forward this point to them?
Cheers.
--
Felipe Contreras
next prev parent reply other threads:[~2021-07-15 17:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-15 2:40 [PATCH 0/5] Handle conflicting pull options Elijah Newren via GitGitGadget
2021-07-15 2:40 ` [PATCH 1/5] pull: move definitions of parse_config_rebase and parse_opt_rebase Elijah Newren via GitGitGadget
2021-07-15 2:40 ` [PATCH 2/5] pull: convert OPT_PASSTHRU for fast-forward options to OPT_CALLBACK Elijah Newren via GitGitGadget
2021-07-15 2:40 ` [PATCH 3/5] pull: handle conflicting rebase/merge options via last option wins Elijah Newren via GitGitGadget
2021-07-15 4:59 ` Eric Sunshine
2021-07-15 17:13 ` Elijah Newren
2021-07-15 9:44 ` Felipe Contreras
2021-07-15 17:33 ` Junio C Hamano
2021-07-15 17:46 ` Felipe Contreras [this message]
2021-07-15 19:04 ` Elijah Newren
2021-07-15 19:58 ` Junio C Hamano
2021-07-15 20:40 ` Elijah Newren
2021-07-15 21:12 ` Junio C Hamano
2021-07-16 18:39 ` Elijah Newren
2021-07-16 21:18 ` Junio C Hamano
2021-07-16 21:56 ` Felipe Contreras
2021-07-15 20:17 ` Junio C Hamano
2021-07-15 20:38 ` Elijah Newren
2021-07-15 2:40 ` [PATCH 4/5] pull: abort if --ff-only is given and fast-forwarding is impossible Alex Henrie via GitGitGadget
2021-07-15 2:40 ` [PATCH 5/5] pull: abort by default when fast-forwarding is not possible Elijah Newren via GitGitGadget
2021-07-15 5:18 ` Eric Sunshine
2021-07-15 16:56 ` Elijah Newren
2021-07-15 9:48 ` Felipe Contreras
2021-07-16 9:32 ` Ævar Arnfjörð Bjarmason
2021-07-16 18:13 ` Felipe Contreras
2021-07-15 9:37 ` [PATCH 0/5] Handle conflicting pull options 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=60f0747b149eb_4b682084c@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=alexhenrie24@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=sluongng@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).