From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Git <git@vger.kernel.org>,
Emily Shaffer <emilyshaffer@google.com>
Subject: Re: fc/pull-merge-rebase, was Re: What's cooking in git.git (Dec 2020, #01; Tue, 8)
Date: Fri, 11 Dec 2020 17:09:38 -0500 [thread overview]
Message-ID: <20201211220938.GB575698@mit.edu> (raw)
In-Reply-To: <xmqqim98inml.fsf@gitster.c.googlers.com>
On Thu, Dec 10, 2020 at 11:17:24PM -0800, Junio C Hamano wrote:
>
> The approach to hold the "future" patch of and keep giving a
> "warning" is still likely to cause damage to people like Ted and
> Dscho (both gave examples of workflowsand automation that currently
> happily creating merges as the user expects, while the user just
> ignores the warning, without being configured at all), when finally
> the "future" patch (after fixing the test breakages, of course)
> lands. They just ignored the current loud messages---I do not see
> any reason to expect the updated "warning" would have any effect on
> them and help them to prepare for the future default change.
At least for me, it won't break me. I'm not using an automation, and
in general, if I'm not going to use "git fetch", what I use is "git
pull --ff-only". If that fails, then I'll fall back to an explicit
"git rebase" or "git merge".
Should I have just set pull.ff=only? Probably, but I've been typing
"git pull --ff-only" as a finger macro for a long time, and I've been
too lazy to get around to update pull.ff in my ~/.gitconfig.
Even if it did break me, compared to, say, changes to how systemd and
journald work compared to syslog and init scripts, or extra gcc/clang
warnings when I update to a newer version of a Linux distribution, the
changes being discussed here are positively picayune. :-)
So if we think it is going to make things better going forward, I for
one am very willing to deal with any short-term pain associated with
changes here.
Cheers,
- Ted
next prev parent reply other threads:[~2020-12-11 22:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 1:31 What's cooking in git.git (Dec 2020, #01; Tue, 8) Junio C Hamano
2020-12-09 1:41 ` Taylor Blau
2020-12-10 2:02 ` Jonathan Tan
2020-12-09 2:45 ` Elijah Newren
2020-12-09 4:22 ` Junio C Hamano
2020-12-09 23:02 ` Taylor Blau
2020-12-10 0:57 ` Junio C Hamano
2020-12-10 2:57 ` Jonathan Tan
2020-12-09 14:09 ` fc/pull-merge-rebase, was " Johannes Schindelin
2020-12-09 21:28 ` Junio C Hamano
2020-12-10 0:31 ` Felipe Contreras
2020-12-10 4:40 ` Johannes Schindelin
2020-12-10 4:46 ` Johannes Schindelin
2020-12-10 15:11 ` Felipe Contreras
2020-12-10 15:27 ` Theodore Y. Ts'o
2020-12-10 18:28 ` Junio C Hamano
2020-12-11 1:33 ` Felipe Contreras
2020-12-11 7:17 ` Junio C Hamano
2020-12-11 14:10 ` Felipe Contreras
2020-12-11 22:09 ` Theodore Y. Ts'o [this message]
2020-12-12 0:43 ` Felipe Contreras
2020-12-10 0:27 ` Felipe Contreras
2020-12-11 5:59 ` Junio C Hamano
2020-12-09 14:11 ` js/init-defaultbranch-advice, " Johannes Schindelin
2020-12-09 21:57 ` Junio C Hamano
2020-12-10 4:54 ` Johannes Schindelin
2020-12-10 18:33 ` Junio C Hamano
2020-12-11 0:03 ` Felipe Contreras
2020-12-10 3:56 ` bc/rev-parse-path-format, " Johannes Schindelin
2020-12-10 18:34 ` Junio C Hamano
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=20201211220938.GB575698@mit.edu \
--to=tytso@mit.edu \
--cc=Johannes.Schindelin@gmx.de \
--cc=emilyshaffer@google.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).