From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Phillip Wood <phillip.wood123@gmail.com>
Cc: Alex Henrie <alexhenrie24@gmail.com>,
git@vger.kernel.org, avarab@gmail.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 12:30:30 -0500 [thread overview]
Message-ID: <60ec7c3636327_a45252081d@natae.notmuch> (raw)
In-Reply-To: <xmqqpmvn5ukj.fsf@gitster.g>
Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
> > 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
> > only not false --no-rebase fast-forward only
> > * not false --ff-only fast-forward only
> > only not false --ff merge --ff
> > only not false --no-ff merge --no-ff
> > only false fast-forward only
> > only false --rebase rebase
> > only false --ff merge --ff
> > only false --no-ff merge --no-ff
>
> Do you mean by "not false" something other than "true"? Are you
> trying to capture what should happen when these configuration
> options are unspecified as well (and your "not false" is "either set
> to true or unspecified")? I ask because the first row does not make
> any sense to me. It seems to say
>
> "If pull.ff is set to 'only', pull.rebase is not set to 'false',
> and the command line does not say anything, we will rebase".
No, pull.rebase can have values other than true, like "merges".
git -c pull.ff=only -c pull.rebase=merges pull
This should rebase because pull.ff=only is meant only for --merge.
> I do agree with you that the command line options
>
> --ff-only
> --ff (aka "allow ff")
> --no-ff
>
> should override pull.ff and
Yes.
> --rebase
> --no-rebase (aka "merge")
>
> should override pull.rebase configuration settings
Yes.
> and also override pull.ff set to 'only'
No.
pull.ff=only is specifically set for when the user wants to do a merge,
*not* a rebase.
git -c pull.ff=only pull # fast-forward merge
git -c pull.ff=only pull --rebase # rebase
git -c pull.ff=only pull --no-rebase # fast-forward merge
Whether the merge is implied becuse it's the default, or the user has
explicitely specified it with --no-rebase (should be --merge) does not
matter.
> (i.e. the user explicitly
> wants intregration of the two histories and at that point "I usually
> just follow along" which is "pull.ff=only" no longer applies).
Nowhere in the description of pull.ff does it say that --no-rebase turns
off pull.ff=only.
pull.ff::
By default, Git does not create an extra merge commit when merging
a commit that is a descendant of the current commit. Instead, the
tip of the current branch is fast-forwarded. When set to `false`,
this variable tells Git to create an extra merge commit in such
a case (equivalent to giving the `--no-ff` option from the command
line). When set to `only`, only such fast-forward merges are
allowed (equivalent to giving the `--ff-only` option from the
command line). This setting overrides `merge.ff` when pulling.
That would be a pretty convoluted semantic change.
And BTW, why would these four produce different results?
git -c pull.ff=only -c pull.rebase=false pull
git -c pull.ff=only pull --no-rebase
git -c pull.rebase=false pull --ff-only
git pull --ff-only --no-rebase
--
Felipe Contreras
next prev parent reply other threads:[~2021-07-12 17:30 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
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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60ec7c3636327_a45252081d@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.