git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: "Jacob Keller" <jacob.keller@gmail.com>,
	"Elijah Newren" <newren@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Vít Ondruch" <vondruch@redhat.com>,
	"Alex Henrie" <alexhenrie24@gmail.com>,
	"Jeff King" <peff@peff.net>,
	"Philip Oakley" <philipoakley@iee.email>,
	"Theodore Y . Ts'o" <tytso@mit.edu>,
	"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: Tue, 08 Dec 2020 12:16:46 -0800	[thread overview]
Message-ID: <xmqqy2i86ok1.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAMP44s3KCoDfRXzarJw5AE7UsY-=eP6GbHzdDcdrs2rsw5tL+w@mail.gmail.com> (Felipe Contreras's message of "Mon, 7 Dec 2020 21:15:05 -0600")

Felipe Contreras <felipe.contreras@gmail.com> writes:

> That is exemplified by the fact that this whole thread started from a
> user that refused to configure pull.rebase and expected the Git
> project to just do the right thing (which is basically choosing a
> useful default).

Which is basically asking for impossible, and I do not think it is a
good idea to focus our effort to satisfy such a request in general.
There is no useful default that suits everybody in this particular
case.

The "force ff-only" approach indeed gives a very sensible default
behaviour of dying for those who haven't expressed the choice
between rebase and merge in a situation where the difference between
the two results in histories of different shapes.

But for anybody who uses git for real (read: produces his or her own
history), it would be pretty much a useless default that forces the
user to say rebase or merge every time 'git pull' is run.  That is
why I am not enthused by the pull.mode=(rebase/merge/ff-only)
configuration.  The third choice does help completeness.  When a
user asks "the documentation tells pull.mode can be set to
non-default behaviour---what value can one set it to to get the
default behaviour of not allowing any original work?", it can be
answered if we had pull.mode=ff-only.  But other than that, I do not
see any real use for the choice, which would mean in practice,
pull.mode would have only two useful values, rebase or merge.  That
does not feel a good enough reason to supersede what already exists,
which is pull.rebase=yes/no.

Perhaps there is a good reason why certain classes of users would
want to configure pull.mode=ff-only (i.e. "I might type 'git pull'
by mistake, please stop me if I did so on a branch I have real work
already.").  If that is the case, I would very much agree that it
would be awkward to express that choice in the current framework to
choose between pull.rebase=yes/no and pull.mode=(rebase/merge/ff-only)
would become a lot easier to explain.

I dunno.

  reply	other threads:[~2020-12-08 20:17 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
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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqy2i86ok1.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=alexhenrie24@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=john@keeping.me.uk \
    --cc=newren@gmail.com \
    --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.
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).