git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	Felipe Contreras <felipe.contreras@gmail.com>
Cc: Git <git@vger.kernel.org>, "Elijah Newren" <newren@gmail.com>,
	"Jeff King" <peff@peff.net>, "Vít Ondruch" <vondruch@redhat.com>
Subject: Re: [PATCH v5 2/3] pull: move default warning
Date: Mon, 14 Dec 2020 05:02:58 -0600	[thread overview]
Message-ID: <5fd7466250a4f_d17f5208fc@natae.notmuch> (raw)
In-Reply-To: <xmqqpn3cep51.fsf@gitster.c.googlers.com>

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > On Fri, Dec 11, 2020 at 6:00 PM Junio C Hamano <gitster@pobox.com> wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >
> >> > Should actually be something like:
> >> >
> >> >         if (rebase_unspecified && !can_ff)
> >> >                 die("Not a fast-forward; must either merge or rebase");
> >>
> >> The illustration I gave in the message you are responding to was
> >> made in the context of patch 2/3; with patch 3/3 where can_ff
> >> exists, it would not become like what you gave above.  It should
> >> instead become
> >>
> >>         if (rebase_unspecified && !opt_ff && !can_ff) {
> >>                 if (opt_verbosity >= 0 && advice_pull_non_ff)
> >>                         show_advice_pull_non_ff();
> >>                 die("not a fast-forward; must merge or rebase");
> >>         }
> >>
> >> i.e. when we can fast-forward, we do not trigger the "you must
> >> specify rebase/merge" message, and we do not trigger the "not a
> >> fast-forward" error.
> >
> > It's not the !can_ff part I'm trying to highlight, it's the lack of
> > advice *after* we have decided to flip the switch.
> >
> > As I said in another thread: I don't think we have any long
> > condescending error in any other command.
> 
> Only the "not a fast-forward and you must choose between merge and
> rebase" part (i.e. what I listed as the first part of three-part
> message) is the error.
> 
> The rest, the message that teaches how to choose between merge and
> rebase from command line and configuration (or how to choose
> permanently not to make the choice between the two), is not an
> error---it's called advice.

Right. After re-reading the 2013 discussion, and the GitHub trainers'
input that Jeff King shared with us [1], it might make sense to
eventually keep this advice (permanently), since many users might not
know what a rebase is, and would not want to know at this point of their
learning curve.

That being said, the advice still needs to be improved, and I have
already yet another version taking this into consideration ready to be
sent. Just waiting for feedback on the previous can_ff series.

> Even if we were to introduce the third choice (i.e. permanently not
> to choose between rebase or merge and instead just error out without
> getting advice), the advice must stay for those who didn't make any
> choice among the three (i.e. merge, rebase or ff-only).

With the introduction of such mode, and the permanent advice, we would
have:

  if (!can_ff) {
	  if (!mode && opt_verbosity >= 0 && advice_pull_non_ff)
		  show_advice_pull_non_ff();

	  if (mode == PULL_MODE_FF_ONLY)
		  die(_("Not a fast-forward, either merge or rebase.\n"));
  }

If in the future we decide to make it the default, we would have:

  if (!can_ff) {
	  if (!mode && opt_verbosity >= 0 && advice_pull_non_ff)
		  show_advice_pull_non_ff();

	  if (!mode || mode == PULL_MODE_FF_ONLY)
		  die(_("Not a fast-forward, either merge or rebase.\n"));
  }

The transition is very straightforward.

> We have many of them.  An easy example to spot is a similar sized
> onefor "git checkout HEAD^0".  Neither that one or the one under
> discussion is particularly condescending.

I am not familiar with these "advices", since I basically ignore them,
and they are not presented to me in any different color, or special
presentation. I generally ignore textwalls in my command line.

But fine, if these walls of text already exist, perhaps it makes sense
to have yet another permanent one (just with better text, and better
options).

With an improved advice--which includes an option that is good enough we
*can* make the default (pull.mode=ff-only)--perhaps that would be
enough, and in a couple of years we can make the assessment if it's
enough or not.

But clearly *today* we don't have such mode, which people have found
missing for more than a decadte.

Cheers.

[1] https://lore.kernel.org/git/20130909201751.GA14437@sigill.intra.peff.net/

-- 
Felipe Contreras

  reply	other threads:[~2020-12-14 11:20 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 10:05 [PATCH v5 0/3] pull: stop warning on every pull Felipe Contreras
2020-12-10 10:05 ` [PATCH v5 1/3] pull: refactor fast-forward check Felipe Contreras
2020-12-11  6:54   ` Junio C Hamano
2020-12-12 15:18     ` Felipe Contreras
2020-12-10 10:05 ` [PATCH v5 2/3] pull: move default warning Felipe Contreras
2020-12-11  6:54   ` Junio C Hamano
2020-12-11  7:55     ` Felipe Contreras
2020-12-12  0:00       ` Junio C Hamano
2020-12-12  1:05         ` Felipe Contreras
2020-12-13 20:58           ` Junio C Hamano
2020-12-14 11:02             ` Felipe Contreras [this message]
2020-12-12 16:42       ` Felipe Contreras
2020-12-10 10:05 ` [PATCH v5 3/3] pull: display default warning only when non-ff Felipe Contreras
2020-12-11  7:16   ` Junio C Hamano
2020-12-11 12:48     ` Felipe Contreras
2020-12-11 23:56       ` Junio C Hamano
2020-12-12  1:01         ` Felipe Contreras
2020-12-12  2:11         ` Junio C Hamano
2020-12-12 16:01           ` Felipe Contreras
2020-12-14 21:04             ` Junio C Hamano
2020-12-14 21:40               ` Felipe Contreras
2020-12-11  7:17 ` [PATCH v5 0/3] pull: stop warning on every pull Junio C Hamano
2020-12-11 13:28   ` Felipe Contreras
2020-12-12  2:50     ` Junio C Hamano
2020-12-12 16:36       ` Felipe Contreras
2020-12-14  0:57         ` Felipe Contreras
  -- strict thread matches above, loose matches on Subject: below --
2020-12-12 16:52 Felipe Contreras
2020-12-12 16:52 ` [PATCH v5 2/3] pull: move default warning 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=5fd7466250a4f_d17f5208fc@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=vondruch@redhat.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).