From: Felipe Contreras <felipe.contreras@gmail.com>
To: Phillip Wood <phillip.wood123@gmail.com>,
Alex Henrie <alexhenrie24@gmail.com>,
git@vger.kernel.org, avarab@gmail.com, gitster@pobox.com,
felipe.contreras@gmail.com, newren@gmail.com
Subject: Re: [PATCH] pull: abort if --ff-only is given and fast-forwarding is impossible
Date: Mon, 12 Jul 2021 11:04:50 -0500 [thread overview]
Message-ID: <60ec682262994_a452520837@natae.notmuch> (raw)
In-Reply-To: <00e246b1-c712-e6a5-5c27-89127d796098@gmail.com>
Phillip Wood wrote:
> On 11/07/2021 02:26, Alex Henrie wrote:
> > The warning about pulling without specifying how to reconcile divergent
> > branches says that after setting pull.rebase to true, --ff-only can
> > still be passed on the command line to require a fast-forward. Make that
> > actually work.
>
> Thanks for revising this patch, I like this approach much better. I do
> however have some concerns about the interaction of pull.ff with the
> rebase config and command line options. I'd naively expect the following
> behavior (where rebase can fast-forward if possible)
>
> pull.ff pull.rebase commandline action
> only not false rebase
Agreed. (pull.ff applies only for --merge)
> only not false --no-rebase fast-forward only
Agreed. (--no-rebase is --merge, and pull.ff applies)
> * not false --ff-only fast-forward only
Disagree. (--ff-only is for --merge)
We would need to change the documentation and the advice warning for
this to be correct.
> only not false --ff merge --ff
Disagree.
This is a rebase, --ff should be ignored.
Junio already proposed --ff and other options to imply a merge [1], but
I already explained why that is problematic [2].
> only not false --no-ff merge --no-ff
Disagree. (ditto)
> only false fast-forward only
> only false --rebase rebase
> only false --ff merge --ff
> only false --no-ff merge --no-ff
Agreed.
> I don't think enforcing fast-forward only for rebases makes sense unless
> it is given on the command line.
But why? This is inconsistent.
Everywhere else in git the configuration is another way of specifying
the command line. This would be the first instance where it would not be
the case.
> If the user gives `--rebase` `--ff-only` on the command line then we
> should either error out or take the last one in which case `pull
> --rebase --ff-only` would fast-forward only but `pull --ff-only
> --rebase` would rebase.
Following the same logic `pull --ff-only --merge` would ignore the
previous --ff-only, wouldn't it?
This is a pretty significant semantic change and nowhere in this patch
it's explained who this is supposed to help, or what is the motivtion
behind it.
[1] https://lore.kernel.org/git/xmqqmtyf8hfm.fsf@gitster.c.googlers.com/
[2] https://lore.kernel.org/git/5fd8aa6a52e81_190cd7208c8@natae.notmuch/
--
Felipe Contreras
next prev parent reply other threads:[~2021-07-12 16:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-11 1:26 [PATCH] pull: abort if --ff-only is given and fast-forwarding is impossible Alex Henrie
2021-07-11 17:08 ` Felipe Contreras
2021-07-11 20:00 ` Alex Henrie
2021-07-11 21:41 ` Felipe Contreras
2021-07-12 10:21 ` Phillip Wood
2021-07-12 16:04 ` Felipe Contreras [this message]
2021-07-12 16:29 ` Alex Henrie
2021-07-12 17:43 ` Felipe Contreras
2021-07-12 17:08 ` Junio C Hamano
2021-07-12 17:30 ` Felipe Contreras
2021-07-12 17:50 ` Elijah Newren
2021-07-12 18:20 ` Felipe Contreras
2021-07-12 18:20 ` Alex Henrie
2021-07-12 18:24 ` Alex Henrie
2021-07-12 19:55 ` Junio C Hamano
2021-07-12 20:19 ` Felipe Contreras
2021-07-12 20:51 ` Elijah Newren
2021-07-12 23:00 ` Junio C Hamano
2021-07-12 23:05 ` Felipe Contreras
2021-07-12 23:24 ` Elijah Newren
2021-07-12 20:37 ` Elijah Newren
2021-07-12 21:06 ` Felipe Contreras
2021-07-12 17:54 ` Phillip Wood
2021-07-14 8:37 ` Son Luong Ngoc
2021-07-14 15:14 ` Felipe Contreras
2021-07-14 15:22 ` Elijah Newren
2021-07-14 17:19 ` Junio C Hamano
2021-07-14 17:31 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60ec682262994_a452520837@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=alexhenrie24@gmail.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=phillip.wood123@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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).