All of lore.kernel.org
 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 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.