Re: fc/pull-merge-rebase, was Re: What's cooking in git.git (Dec 2020, #01; Tue, 8)

From: Theodore Y. Ts'o <tytso@mit.edu>
Date: Dec 11, 2020, 22:09 UTC
Message-ID: <20201211220938.GB575698@mit.edu>
In-Reply-To: <xmqqim98inml.fsf@gitster.c.googlers.com>

On Thu, Dec 10, 2020 at 11:17:24PM -0800, Junio C Hamano wrote:

Show 10 quoted lines

> 
> 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