From: Elijah Newren <newren@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
"Vít Ondruch" <vondruch@redhat.com>,
"Alex Henrie" <alexhenrie24@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>,
"Philip Oakley" <philipoakley@iee.email>,
"Theodore Y . Ts'o" <tytso@mit.edu>,
"Jacob Keller" <jacob.keller@gmail.com>,
"John Keeping" <john@keeping.me.uk>,
"Richard Hansen" <rhansen@rhansen.org>,
"Brian M. Carlson" <sandals@crustytoothpaste.net>,
"W. Trevor King" <wking@tremily.us>
Subject: Re: [PATCH v2 02/14] pull: improve default warning
Date: Fri, 4 Dec 2020 16:56:14 -0800 [thread overview]
Message-ID: <CABPp-BFwWBLdFPsKi3o9hznFtAeWWfhNAyuymPS4BhMAHpnSfw@mail.gmail.com> (raw)
In-Reply-To: <CAMP44s1eTc4+tbULbyz5ENgbcN4tOVBA3Z-4GS4yMpciUD_1Hw@mail.gmail.com>
Hi Felipe,
On Fri, Dec 4, 2020 at 4:12 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Fri, Dec 4, 2020 at 5:00 PM Elijah Newren <newren@gmail.com> wrote:
> >
> > On Thu, Dec 3, 2020 at 10:16 PM Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> > >
> > > We want to:
> > >
> > > 1. Be clear about what "specifying" means; merge or rebase.
> > > 2. Mention a direct shortcut for people that just want to get on with
> > > their lives: git pull --no-rebase.
> >
> > This is a shortcut for what?
>
> git config --global pull.rebase false
> git pull
>
> It's a shorter way of saying: "do a 'git pull' like you've always done
> but don't warn me".
>
> > > 3. Have a quick reference for users to understand what this
> > > "fast-forward" business means.
> > >
> > > This patch does all three.
> > >
> > > Thanks to the previous patch now "git pull --help" explains what a
> > > fast-forward is, and a further patch changes --no-rebase to --merge so
> > > it's actually user friendly.
> > >
> > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > > ---
> > > builtin/pull.c | 23 ++++++++++++-----------
> > > 1 file changed, 12 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/builtin/pull.c b/builtin/pull.c
> > > index 1034372f8b..22a9ffcade 100644
> > > --- a/builtin/pull.c
> > > +++ b/builtin/pull.c
> > > @@ -346,17 +346,18 @@ static enum rebase_type config_get_rebase(void)
> > >
> > > if (opt_verbosity >= 0 && !opt_ff) {
> > > advise(_("Pulling without specifying how to reconcile divergent branches is\n"
> > > - "discouraged. You can squelch this message by running one of the following\n"
> > > - "commands sometime before your next pull:\n"
> > > - "\n"
> > > - " git config pull.rebase false # merge (the default strategy)\n"
> > > - " git config pull.rebase true # rebase\n"
> > > - " git config pull.ff only # fast-forward only\n"
> > > - "\n"
> > > - "You can replace \"git config\" with \"git config --global\" to set a default\n"
> > > - "preference for all repositories. You can also pass --rebase, --no-rebase,\n"
> > > - "or --ff-only on the command line to override the configured default per\n"
> > > - "invocation.\n"));
> > > + "discouraged; you need to specify if you want a merge, or a rebase.\n"
> >
> > ...want a merge, a rebase, or neither.
>
> There is no "git pull --no-merge". Years ago some people argued for a
> "pull.mode=none" (essentially making "git pull" the same as "git
> fetch"). But right now there's no option to do that.
>
> There's an option to do --ff-only, but that's still a merge.
I disagree. I'm well aware that checkout_fast_forward() (which is
what is ultimately called to do the fast-forwarding) is in a file
called merge.c, but that doesn't make it a merge. I don't believe it
was anything more than a convenient place to dump some extra code at
the time.
> Perhaps: a merge, a rebase, or a fast-forward?
Sure, that works; in fact, that's much better than my suggestion. I like it.
> > > + "You can squelch this message by running one of the following commands:\n"
> > > + "\n"
> > > + " git config pull.rebase false # merge (the default strategy)\n"
> >
> > Should this be labelled as the default given the desire to make
> > --ff-only the default? Perhaps I'm jumping ahead and you plan to
> > change that later in this series.
>
> That's right.
>
> In the previous series which does indeed make "pull.mode=ff-only" the
> default [1], I do change the warning to specify the future default
> [2], but in that series the warnings is changed to:
>
> The pull was not fast-forward, in the future you will have to choose
> a merge, or a rebase.
> To squelch this message and maintain the current behavior, use:
>
> git config --global pull.mode merge
>
> To squelch this message and adopt the new behavior now, use:
>
> git config --global push.mode ff-only
>
> Falling back to old style for now (merge).
> Read "git pull --help" for more information.
>
> Since that series didn't get any traction, I decided to only implement
> step 1: fix the current situation. And later on another series would
> do step 2: introduce "pull.mode=ff-only" and do the preparations to
> make it the default.
I like this longer plan. However, on the shorter scale plan...I think
the suggestion to use "git pull --no-rebase" makes the current
situation worse rather than fixing it.
> > > + " git config pull.rebase true # rebase\n"
> > > + " git config pull.ff only # fast-forward only\n"
> > > + "\n"
> > > + "You can replace \"git config\" with \"git config --global\" to set a default\n"
> > > + "preference for all repositories.\n"
> >
> > Good up to here.
> >
> > > + "If unsure, run \"git pull --no-rebase\".\n"
> >
> > Why is that safe to suggest? The original text may not have been the
> > easiest to parse, but this seems more problematic to me.
>
> Because "git pull" has been doing the same as "git pull --no-rebase"
> for more than a decade. It's safe for people to continue with this
> behavior for a few more months.
>
> Some people need to get things done today, and they are not interested
> in future changes, nor changing their default configuration, or what
> the warning has to say.
>
> They just want "git pull" to do the same as yesterday, and the year
> before, without being bothered with an annoying warning.
>
> Those people can start training their fingers to do "git pull
> --merge", and learn the problems with "git pull" later.
>
> We want to respect the user's time, and not force them to read the
> warning today.
The warning was added because sending users down paths that break
things badly is a waste of user's time, and often a much bigger waste
of user's time than making them read up on the meaning behind the two
different choices of what kind of changes they can make. I agree the
warning went too far, but I fully agree with the original folks who
put this warning here that we need to have it for at least some cases
and that there is a decision to be made. Though I am just one voice,
and perhaps others will agree with you on your point here, I'll
continue to disagree with blindly suggesting "git pull --no-rebase".
> > > + "Read \"git pull --help\" for more information."
> >
> > Nice addition.
>
> Especially since now it explains what a fast-forward is.
Indeed. :-)
next prev parent reply other threads:[~2020-12-05 1:00 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 6:16 [PATCH v2 00/14] pull: default warning improvements Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 01/14] doc: pull: explain what is a fast-forward Felipe Contreras
2020-12-04 22:55 ` Elijah Newren
2020-12-05 1:21 ` Jacob Keller
2020-12-04 6:16 ` [PATCH v2 02/14] pull: improve default warning Felipe Contreras
2020-12-04 22:59 ` Elijah Newren
2020-12-05 0:12 ` Felipe Contreras
2020-12-05 0:56 ` Elijah Newren [this message]
2020-12-05 1:56 ` Felipe Contreras
2020-12-05 9:23 ` Chris Torek
2020-12-05 11:47 ` Felipe Contreras
2020-12-05 16:28 ` Elijah Newren
2020-12-05 21:27 ` Felipe Contreras
2020-12-06 1:01 ` Elijah Newren
2020-12-06 14:31 ` Felipe Contreras
2020-12-07 7:26 ` Junio C Hamano
2020-12-07 9:16 ` Felipe Contreras
2020-12-07 18:16 ` Junio C Hamano
2020-12-07 19:09 ` Felipe Contreras
2020-12-07 19:53 ` Junio C Hamano
2020-12-07 22:14 ` Felipe Contreras
2020-12-07 23:30 ` Jacob Keller
2020-12-08 2:23 ` Junio C Hamano
2020-12-08 3:15 ` Felipe Contreras
2020-12-08 20:16 ` Junio C Hamano
2020-12-09 9:52 ` Felipe Contreras
2020-12-09 19:05 ` Elijah Newren
2020-12-10 2:39 ` Felipe Contreras
2020-12-10 6:45 ` Junio C Hamano
2020-12-10 9:08 ` Felipe Contreras
2020-12-10 10:01 ` Felipe Contreras
2020-12-11 7:17 ` Junio C Hamano
2020-12-11 11:33 ` Felipe Contreras
2020-12-14 21:04 ` Junio C Hamano
2020-12-14 22:30 ` Felipe Contreras
2020-12-14 23:14 ` Junio C Hamano
2020-12-15 2:36 ` Felipe Contreras
2020-12-15 2:31 ` Jeff King
2020-12-15 3:49 ` Felipe Contreras
2020-12-15 11:18 ` Junio C Hamano
2020-12-15 12:53 ` Felipe Contreras
2020-12-07 9:23 ` Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 03/14] pull: refactor fast-forward check Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 04/14] pull: cleanup autostash check Felipe Contreras
2020-12-04 23:07 ` Elijah Newren
2020-12-05 0:47 ` Felipe Contreras
2020-12-05 0:57 ` Elijah Newren
2020-12-04 6:16 ` [PATCH v2 05/14] pull: trivial cleanup Felipe Contreras
2020-12-04 23:09 ` Elijah Newren
2020-12-05 0:48 ` Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 06/14] pull: move default warning Felipe Contreras
2020-12-04 23:18 ` Elijah Newren
2020-12-04 23:36 ` Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 07/14] pull: display default warning only when non-ff Felipe Contreras
2020-12-04 23:24 ` Elijah Newren
2020-12-05 1:03 ` Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 08/14] pull: trivial whitespace style fix Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 09/14] pull: introduce --merge option Felipe Contreras
2020-12-04 23:27 ` Elijah Newren
2020-12-05 1:06 ` Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 10/14] pull: add proper error with --ff-only Felipe Contreras
2020-12-04 23:34 ` Elijah Newren
2020-12-05 1:18 ` Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 11/14] tentative: pull: change the semantics of --ff-only Felipe Contreras
2020-12-04 23:39 ` Elijah Newren
2020-12-05 4:01 ` Felipe Contreras
2020-12-05 4:06 ` [PATCH] experiment: pull: change --ff-only and default mode Felipe Contreras
2020-12-05 17:29 ` Elijah Newren
2020-12-05 18:16 ` Felipe Contreras
2020-12-07 7:34 ` Junio C Hamano
2020-12-05 11:37 ` [PATCH v2 11/14] tentative: pull: change the semantics of --ff-only Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 12/14] pull: show warning with --ff Felipe Contreras
2020-12-04 23:41 ` Elijah Newren
2020-12-05 1:25 ` Felipe Contreras
2020-12-04 6:16 ` [PATCH v2 13/14] test: merge-pull-config: trivial cleanup Felipe Contreras
2020-12-04 23:41 ` Elijah Newren
2020-12-04 6:16 ` [PATCH v2 14/14] test: pull-options: revert unnecessary changes Felipe Contreras
2020-12-04 23:49 ` Elijah Newren
2020-12-05 1:28 ` 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=CABPp-BFwWBLdFPsKi3o9hznFtAeWWfhNAyuymPS4BhMAHpnSfw@mail.gmail.com \
--to=newren@gmail.com \
--cc=alexhenrie24@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jacob.keller@gmail.com \
--cc=john@keeping.me.uk \
--cc=peff@peff.net \
--cc=philipoakley@iee.email \
--cc=rhansen@rhansen.org \
--cc=sandals@crustytoothpaste.net \
--cc=tytso@mit.edu \
--cc=vondruch@redhat.com \
--cc=wking@tremily.us \
/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).