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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Dec 10, 2020, 00:27 UTC
Message-ID: <CAMP44s1dRKPtVr9Oazg_JR2WWMhNC_2rx7G4k3qME5FM4L4xTA@mail.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.2012091502000.25979@tvgsbejvaqbjf.bet>

On Wed, Dec 9, 2020 at 9:12 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 35 quoted lines

> On Tue, 8 Dec 2020, Junio C Hamano wrote:
>
> > * fc/pull-merge-rebase (2020-12-08) 19 commits
> >  - future: pull: enable ff-only mode by default
> >  - pull: advice of future changes
> >  - pull: add pull.mode=ff-only
> >  - pull: add pull.mode
> >  - pull: trivial memory fix
> >  - test: pull-options: revert unnecessary changes
> >  - test: merge-pull-config: trivial cleanup
> >  - pull: move configurations fetches
> >  - rebase: add REBASE_DEFAULT
> >  - pull: show warning with --ff
> >  - pull: introduce --merge option
> >  - pull: trivial whitespace style fix
> >  - pull: display default warning only when non-ff
> >  - pull: move default warning
> >  - pull: trivial cleanup
> >  - pull: cleanup autostash check
> >  - pull: refactor fast-forward check
> >  - pull: improve default warning
> >  - doc: pull: explain what is a fast-forward
> >
> >  When a user does not tell "git pull" to use rebase or merge, the
> >  command gives a loud message telling a user to choose between
> >  rebase or merge but creates a merge anyway, forcing users who would
> >  want to rebase to redo the operation.  Fix this by (1) tightening
> >  the condition to give the message---there is no reason to stop or
> >  force the user to choose between rebase or merge if the history
> >  fast-forwards, and (2) failing the operation when the history does
> >  not fast-forward, instead of making a merge, in such a case.
>
> Despite what the commit message of the tip commit says, it is not "time to
> flip the switch and make ff-only the default" because it breaks our very
> own test suite left and right. See for yourself:

The commit is prefixed with "future:" it's not meant to be applied today, but months after the previous patch, perhaps even in Git 3.0.

Show 7 quoted lines

> Given that not even our very own test suite is well-suited to this change,
> I rather doubt that this is a safe thing to do.
>
> In the _least_, the patch series should put in the effort to show just how
> much work it is to adjust the test suite to let it pass again. This would
> also give an indication how much work we impose on our users by that
> ff-only change in behavior.

The commit is already there:

https://gitlab.com/felipec/git/-/commit/29a28ad763d3231eb1e22867dcfa56e53c5b2be6

But I did not want to overwhelm the mailing list with a mundane change that does nothing to move forward the conversation.

Hopefully you are not implying I haven't put enough effort (since static objects--like a patch series--can't put effort).

Cheers.

Cheers.

-- 
Felipe Contreras