git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: fc/pull-merge-rebase, was Re: What's cooking in git.git (Dec 2020, #01; Tue, 8)
Date: Wed, 9 Dec 2020 15:09:03 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2012091502000.25979@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqqpn3j4ved.fsf@gitster.c.googlers.com>

Hi Junio,

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:

https://github.com/gitgitgadget/git/runs/1521231966?check_suite_focus=true
claims that a whopping 120 (!!!) test cases fail. Here's the exact list:

Test Summary Report
-------------------
t4013-diff-various.sh                            (Wstat: 256 Tests: 195
Failed: 84)
  Failed tests:  1, 49-62, 66-68, 70-84, 94-109, 113-117
                120-123, 131-134, 137-138, 140-143, 145-146
                164-168, 182-186, 188-191
  Non-zero exit status: 1
t5524-pull-msg.sh                                (Wstat: 256 Tests: 3
Failed: 2)
  Failed tests:  2-3
  Non-zero exit status: 1
t5521-pull-options.sh                            (Wstat: 256 Tests: 20
Failed: 2)
  Failed tests:  12, 16
  Non-zero exit status: 1
t5553-set-upstream.sh                            (Wstat: 256 Tests: 19
Failed: 6)
  Failed tests:  11-14, 16-17
  Non-zero exit status: 1
t5520-pull.sh                                    (Wstat: 256 Tests: 81
Failed: 8)
  Failed tests:  16, 33-39
  Non-zero exit status: 1
t5604-clone-reference.sh                         (Wstat: 256 Tests: 33
Failed: 4)
  Failed tests:  13-16
  Non-zero exit status: 1
t6409-merge-subtree.sh                           (Wstat: 256 Tests: 12
Failed: 3)
  Failed tests:  9, 11-12
  Non-zero exit status: 1
t6417-merge-ours-theirs.sh                       (Wstat: 256 Tests: 7
Failed: 1)
  Failed test:  6
  Non-zero exit status: 1
t6402-merge-rename.sh                            (Wstat: 256 Tests: 46
Failed: 8)
  Failed tests:  2-8, 11
  Non-zero exit status: 1
t7603-merge-reduce-heads.sh                      (Wstat: 256 Tests: 13
Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
Files=915, Tests=22158, 448 wallclock secs ( 5.63 usr  1.64 sys + 555.46
cusr 190.71 csys = 753.44 CPU)
Result: FAIL

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.

Ciao,
Dscho

  parent reply	other threads:[~2020-12-09 14:10 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 ` Johannes Schindelin [this message]
2020-12-09 21:28   ` fc/pull-merge-rebase, was " 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
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

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

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2012091502000.25979@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --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.
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).