[PATCH v5 0/3] pull: stop warning on every pull

[PATCH v5 0/3] pull: stop warning on every pull

[Felipe Contreras]

The discussion about making fast-forward-only pulls the default is stuck on mud, and there's no
agreement about what we should even be warning our users about.

Even my straightforward patches about improving documentation, and the consistency of the UI with
--merge and other obvious fixes lost traction.

This is not the totality of part I, it's doing one thing, and one thing only: stops warning the
users on every single pull (warns only if they are not-fast-forward).

Everything else is dropped.

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 21b50aff77..5c3fb67c01 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -38,20 +38,6 @@ as set by linkgit:git-branch[1] `--track`.
 Assume the following history exists and the current branch is
 "`master`":
 
-------------
-	  A---B---C master on origin
-	 /
-    D---E master
-------------
-
-Then `git pull` will merge in a fast-forward way up to the new master.
-
-------------
-    D---E---A---B---C master, origin/master
-------------
-
-However, a non-fast-forward case looks very different.
-
 ------------
 	  A---B---C master on origin
 	 /
@@ -60,9 +46,6 @@ However, a non-fast-forward case looks very different.
 	origin/master in your repository
 ------------
 
-By default `git pull` will warn about these situations, however, most likely
-you would want to force a merge, which you can do with `git pull --merge`.
-
 Then "`git pull`" will fetch and replay the changes from the remote
 `master` branch since it diverged from the local `master` (i.e., `E`)
 until its current commit (`C`) on top of `master` and record the
@@ -148,11 +131,8 @@ It rewrites history, which does not bode well when you
 published that history already.  Do *not* use this option
 unless you have read linkgit:git-rebase[1] carefully.
 
--m::
---merge::
-	Force a merge.
-+
-Previously this was --no-rebase, but that usage has been deprecated.
+--no-rebase::
+	Override earlier --rebase.
 
 Options related to fetching
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/builtin/pull.c b/builtin/pull.c
index 118fbdeb62..9a7caf3a3e 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -27,6 +27,8 @@
 #include "commit-reach.h"
 #include "sequencer.h"
 
+static int default_mode;
+
 /**
  * Parses the value of --rebase. If value is a false value, returns
  * REBASE_FALSE. If value is a true value, returns REBASE_TRUE. If value is
@@ -74,7 +76,7 @@ static char *opt_progress;
 static int recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
 
 /* Options passed to git-merge or git-rebase */
-static enum rebase_type opt_rebase;
+static enum rebase_type opt_rebase = -1;
 static char *opt_diffstat;
 static char *opt_log;
 static char *opt_signoff;
@@ -126,11 +128,9 @@ static struct option pull_options[] = {
 	/* Options passed to git-merge or git-rebase */
 	OPT_GROUP(N_("Options related to merging")),
 	OPT_CALLBACK_F('r', "rebase", &opt_rebase,
-		"(false|true|merges|preserve|interactive)",
-		N_("incorporate changes by rebasing rather than merging"),
-		PARSE_OPT_OPTARG, parse_opt_rebase),
-	OPT_SET_INT('m', "merge", &opt_rebase,
-		N_("incorporate changes by merging"), REBASE_FALSE),
+	  "(false|true|merges|preserve|interactive)",
+	  N_("incorporate changes by rebasing rather than merging"),
+	  PARSE_OPT_OPTARG, parse_opt_rebase),
 	OPT_PASSTHRU('n', NULL, &opt_diffstat, NULL,
 		N_("do not show a diffstat at the end of the merge"),
 		PARSE_OPT_NOARG | PARSE_OPT_NONEG),
@@ -346,7 +346,9 @@ static enum rebase_type config_get_rebase(void)
 	if (!git_config_get_value("pull.rebase", &value))
 		return parse_config_rebase("pull.rebase", value, 1);
 
-	return REBASE_DEFAULT;
+	default_mode = 1;
+
+	return REBASE_FALSE;
 }
 
 /**
@@ -441,7 +443,7 @@ static void NORETURN die_no_merge_candidates(const char *repo, const char **refs
 	const char *remote = curr_branch ? curr_branch->remote_name : NULL;
 
 	if (*refspecs) {
-		if (opt_rebase >= REBASE_TRUE)
+		if (opt_rebase)
 			fprintf_ln(stderr, _("There is no candidate for rebasing against among the refs that you just fetched."));
 		else
 			fprintf_ln(stderr, _("There are no candidates for merging among the refs that you just fetched."));
@@ -454,7 +456,7 @@ static void NORETURN die_no_merge_candidates(const char *repo, const char **refs
 			repo);
 	} else if (!curr_branch) {
 		fprintf_ln(stderr, _("You are not currently on a branch."));
-		if (opt_rebase >= REBASE_TRUE)
+		if (opt_rebase)
 			fprintf_ln(stderr, _("Please specify which branch you want to rebase against."));
 		else
 			fprintf_ln(stderr, _("Please specify which branch you want to merge with."));
@@ -469,7 +471,7 @@ static void NORETURN die_no_merge_candidates(const char *repo, const char **refs
 			remote_name = _("<remote>");
 
 		fprintf_ln(stderr, _("There is no tracking information for the current branch."));
-		if (opt_rebase >= REBASE_TRUE)
+		if (opt_rebase)
 			fprintf_ln(stderr, _("Please specify which branch you want to rebase against."));
 		else
 			fprintf_ln(stderr, _("Please specify which branch you want to merge with."));
@@ -931,11 +933,9 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 	struct oid_array merge_heads = OID_ARRAY_INIT;
 	struct object_id orig_head, curr_head;
 	struct object_id rebase_fork_point;
+	int autostash;
 	int can_ff;
 
-	opt_ff = xstrdup_or_null(config_get_ff());
-	opt_rebase = config_get_rebase();
-
 	if (!getenv("GIT_REFLOG_ACTION"))
 		set_reflog_message(argc, argv);
 
@@ -952,6 +952,12 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 
 	parse_repo_refspecs(argc, argv, &repo, &refspecs);
 
+	if (!opt_ff)
+		opt_ff = xstrdup_or_null(config_get_ff());
+
+	if (opt_rebase < 0)
+		opt_rebase = config_get_rebase();
+
 	if (read_cache_unmerged())
 		die_resolve_conflict("pull");
 
@@ -961,8 +967,8 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 	if (get_oid("HEAD", &orig_head))
 		oidclr(&orig_head);
 
-	if (opt_rebase >= REBASE_TRUE) {
-		int autostash = config_autostash;
+	autostash = config_autostash;
+	if (opt_rebase) {
 		if (opt_autostash != -1)
 			autostash = opt_autostash;
 
@@ -1021,28 +1027,29 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 			die(_("Cannot merge multiple branches into empty head."));
 		return pull_into_void(merge_heads.oid, &curr_head);
 	}
-	if (opt_rebase >= REBASE_TRUE && merge_heads.nr > 1)
+	if (opt_rebase && merge_heads.nr > 1)
 		die(_("Cannot rebase onto multiple branches."));
 
 	can_ff = get_can_ff(&orig_head, &merge_heads.oid[0]);
 
-	if (!opt_rebase && !can_ff && opt_verbosity >= 0 && (!opt_ff || !strcmp(opt_ff, "--ff"))) {
-		advise(_("Pulling without specifying how to reconcile divergent branches is discouraged;\n"
-			"you need to specify if you want a merge, or a rebase.\n"
-			"You can squelch this message by running one of the following commands:\n"
-			"\n"
-			"  git config pull.rebase false  # merge (the default strategy)\n"
-			"  git config pull.rebase true   # rebase\n"
-			"  git config pull.ff only       # fast-forward only\n"
-			"\n"
-			"You can replace \"git config\" with \"git config --global\" to set a default\n"
-			"preference for all repositories.\n"
-			"If unsure, run \"git pull --merge\".\n"
-			"Read \"git pull --help\" for more information."));
+	if (default_mode && !can_ff && opt_verbosity >= 0 && !opt_ff) {
+		advise(_("Pulling without specifying how to reconcile divergent branches is\n"
+			 "discouraged. You can squelch this message by running one of the following\n"
+			 "commands sometime before your next pull:\n"
+			 "\n"
+			 "  git config pull.rebase false  # merge (the default strategy)\n"
+			 "  git config pull.rebase true   # rebase\n"
+			 "  git config pull.ff only       # fast-forward only\n"
+			 "\n"
+			 "You can replace \"git config\" with \"git config --global\" to set a default\n"
+			 "preference for all repositories. You can also pass --rebase, --no-rebase,\n"
+			 "or --ff-only on the command line to override the configured default per\n"
+			 "invocation.\n"));
 	}
 
-	if (opt_rebase >= REBASE_TRUE) {
+	if (opt_rebase) {
 		int ret = 0;
+		int ran_ff = 0;
 
 		struct object_id newbase;
 		struct object_id upstream;
@@ -1053,15 +1060,16 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 		     recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND) &&
 		    submodule_touches_in_range(the_repository, &upstream, &curr_head))
 			die(_("cannot rebase with locally recorded submodule modifications"));
-
-		if (can_ff) {
-			/* we can fast-forward this without invoking rebase */
-			free(opt_ff);
-			opt_ff = xstrdup_or_null("--ff-only");
-			ret = run_merge();
-		} else {
-			ret = run_rebase(&newbase, &upstream);
+		if (!autostash) {
+			if (can_ff) {
+				/* we can fast-forward this without invoking rebase */
+				opt_ff = "--ff-only";
+				ran_ff = 1;
+				ret = run_merge();
+			}
 		}
+		if (!ran_ff)
+			ret = run_rebase(&newbase, &upstream);
 
 		if (!ret && (recurse_submodules == RECURSE_SUBMODULES_ON ||
 			     recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND))
diff --git a/rebase.h b/rebase.h
index 34d4acfd74..cc723d4748 100644
--- a/rebase.h
+++ b/rebase.h
@@ -3,8 +3,7 @@
 
 enum rebase_type {
 	REBASE_INVALID = -1,
-	REBASE_DEFAULT = 0,
-	REBASE_FALSE,
+	REBASE_FALSE = 0,
 	REBASE_TRUE,
 	REBASE_PRESERVE,
 	REBASE_MERGES,
diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh
index 1a4fe2583a..db1a381cd9 100755
--- a/t/t5521-pull-options.sh
+++ b/t/t5521-pull-options.sh
@@ -11,10 +11,10 @@ test_expect_success 'setup' '
 	 git commit -m one)
 '
 
-test_expect_success 'git pull -q' '
+test_expect_success 'git pull -q --no-rebase' '
 	mkdir clonedq &&
 	(cd clonedq && git init &&
-	git pull -q "../parent" >out 2>err &&
+	git pull -q --no-rebase "../parent" >out 2>err &&
 	test_must_be_empty err &&
 	test_must_be_empty out)
 '
@@ -30,10 +30,10 @@ test_expect_success 'git pull -q --rebase' '
 	test_must_be_empty out)
 '
 
-test_expect_success 'git pull' '
+test_expect_success 'git pull --no-rebase' '
 	mkdir cloned &&
 	(cd cloned && git init &&
-	git pull "../parent" >out 2>err &&
+	git pull --no-rebase "../parent" >out 2>err &&
 	test -s err &&
 	test_must_be_empty out)
 '
@@ -46,10 +46,10 @@ test_expect_success 'git pull --rebase' '
 	test_must_be_empty out)
 '
 
-test_expect_success 'git pull -v' '
+test_expect_success 'git pull -v --no-rebase' '
 	mkdir clonedv &&
 	(cd clonedv && git init &&
-	git pull -v "../parent" >out 2>err &&
+	git pull -v --no-rebase "../parent" >out 2>err &&
 	test -s err &&
 	test_must_be_empty out)
 '
@@ -62,25 +62,25 @@ test_expect_success 'git pull -v --rebase' '
 	test_must_be_empty out)
 '
 
-test_expect_success 'git pull -v -q' '
+test_expect_success 'git pull -v -q --no-rebase' '
 	mkdir clonedvq &&
 	(cd clonedvq && git init &&
-	git pull -v -q "../parent" >out 2>err &&
+	git pull -v -q --no-rebase "../parent" >out 2>err &&
 	test_must_be_empty out &&
 	test_must_be_empty err)
 '
 
-test_expect_success 'git pull -q -v' '
+test_expect_success 'git pull -q -v --no-rebase' '
 	mkdir clonedqv &&
 	(cd clonedqv && git init &&
-	git pull -q -v "../parent" >out 2>err &&
+	git pull -q -v --no-rebase "../parent" >out 2>err &&
 	test_must_be_empty out &&
 	test -s err)
 '
 test_expect_success 'git pull --cleanup errors early on invalid argument' '
 	mkdir clonedcleanup &&
 	(cd clonedcleanup && git init &&
-	test_must_fail git pull --cleanup invalid "../parent" >out 2>err &&
+	test_must_fail git pull --no-rebase --cleanup invalid "../parent" >out 2>err &&
 	test_must_be_empty out &&
 	test -s err)
 '
diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
index 8a6aae564a..6b4adab8b1 100755
--- a/t/t7601-merge-pull-config.sh
+++ b/t/t7601-merge-pull-config.sh
@@ -33,6 +33,7 @@ test_expect_success 'pull.rebase not set' '
 	test_decode_color <err >decoded &&
 	test_i18ngrep "<YELLOW>hint: " decoded &&
 	test_i18ngrep "Pulling without specifying how to reconcile" decoded
+
 '
 
 test_expect_success 'pull.rebase not set (fast-forward)' '
@@ -45,7 +46,7 @@ test_expect_success 'pull.rebase not set and pull.ff=true' '
 	git reset --hard c2 &&
 	test_config pull.ff true &&
 	git pull . c1 2>err &&
-	test_i18ngrep "Pulling without specifying how to reconcile" err
+	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and pull.ff=false' '
@@ -68,16 +69,16 @@ test_expect_success 'pull.rebase not set and --rebase given' '
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
-test_expect_success 'pull.rebase not set and --merge given' '
+test_expect_success 'pull.rebase not set and --no-rebase given' '
 	git reset --hard c2 &&
-	git pull --merge . c1 2>err &&
+	git pull --no-rebase . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --ff given' '
 	git reset --hard c2 &&
 	git pull --ff . c1 2>err &&
-	test_i18ngrep "Pulling without specifying how to reconcile" err
+	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --no-ff given' '


Felipe Contreras (3):
  pull: refactor fast-forward check
  pull: move default warning
  pull: display default warning only when non-ff

 builtin/pull.c               | 61 +++++++++++++++++++++---------------
 t/t7601-merge-pull-config.sh | 28 ++++++++++-------
 2 files changed, 53 insertions(+), 36 deletions(-)

-- 
2.29.2

[PATCH v5 1/3] pull: refactor fast-forward check

[Felipe Contreras]

It's much cleaner this way.

Also, we would like to be able to make this check before the decision to
rebase is made.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 builtin/pull.c | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/builtin/pull.c b/builtin/pull.c
index aa56ebcdd0..03e6d53243 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -924,6 +924,20 @@ static int run_rebase(const struct object_id *newbase,
 	return ret;
 }
 
+static int get_can_ff(struct object_id *orig_head, struct object_id *orig_merge_head)
+{
+	int ret;
+	struct commit_list *list = NULL;
+	struct commit *merge_head, *head;
+
+	head = lookup_commit_reference(the_repository, orig_head);
+	commit_list_insert(head, &list);
+	merge_head = lookup_commit_reference(the_repository, orig_merge_head);
+	ret = repo_is_descendant_of(the_repository, merge_head, list);
+	free_commit_list(list);
+	return ret;
+}
+
 int cmd_pull(int argc, const char **argv, const char *prefix)
 {
 	const char *repo, **refspecs;
@@ -1040,22 +1054,12 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 		    submodule_touches_in_range(the_repository, &upstream, &curr_head))
 			die(_("cannot rebase with locally recorded submodule modifications"));
 		if (!autostash) {
-			struct commit_list *list = NULL;
-			struct commit *merge_head, *head;
-
-			head = lookup_commit_reference(the_repository,
-						       &orig_head);
-			commit_list_insert(head, &list);
-			merge_head = lookup_commit_reference(the_repository,
-							     &merge_heads.oid[0]);
-			if (repo_is_descendant_of(the_repository,
-						  merge_head, list)) {
+			if (get_can_ff(&orig_head, &merge_heads.oid[0])) {
 				/* we can fast-forward this without invoking rebase */
 				opt_ff = "--ff-only";
 				ran_ff = 1;
 				ret = run_merge();
 			}
-			free_commit_list(list);
 		}
 		if (!ran_ff)
 			ret = run_rebase(&newbase, &upstream);
-- 
2.29.2

[PATCH v5 2/3] pull: move default warning

[Felipe Contreras]

Eventually we want to be able to display the warning only when
fast-forward merges are not possible.

In order to do so we need to move the default warning up to the point
where we can check if we can fast-forward or not.

Additionally, config_get_rebase() was probably never its true home.

This requires a temporary variable to check if we are in the
"default mode" (no --rebase or --no-rebase specified).

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 builtin/pull.c | 32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/builtin/pull.c b/builtin/pull.c
index 03e6d53243..ff8e3ce137 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -27,6 +27,8 @@
 #include "commit-reach.h"
 #include "sequencer.h"
 
+static int default_mode;
+
 /**
  * Parses the value of --rebase. If value is a false value, returns
  * REBASE_FALSE. If value is a true value, returns REBASE_TRUE. If value is
@@ -344,20 +346,7 @@ static enum rebase_type config_get_rebase(void)
 	if (!git_config_get_value("pull.rebase", &value))
 		return parse_config_rebase("pull.rebase", value, 1);
 
-	if (opt_verbosity >= 0 && !opt_ff) {
-		advise(_("Pulling without specifying how to reconcile divergent branches is\n"
-			 "discouraged. You can squelch this message by running one of the following\n"
-			 "commands sometime before your next pull:\n"
-			 "\n"
-			 "  git config pull.rebase false  # merge (the default strategy)\n"
-			 "  git config pull.rebase true   # rebase\n"
-			 "  git config pull.ff only       # fast-forward only\n"
-			 "\n"
-			 "You can replace \"git config\" with \"git config --global\" to set a default\n"
-			 "preference for all repositories. You can also pass --rebase, --no-rebase,\n"
-			 "or --ff-only on the command line to override the configured default per\n"
-			 "invocation.\n"));
-	}
+	default_mode = 1;
 
 	return REBASE_FALSE;
 }
@@ -1040,6 +1029,21 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 	if (opt_rebase && merge_heads.nr > 1)
 		die(_("Cannot rebase onto multiple branches."));
 
+	if (default_mode && opt_verbosity >= 0 && !opt_ff) {
+		advise(_("Pulling without specifying how to reconcile divergent branches is\n"
+			 "discouraged. You can squelch this message by running one of the following\n"
+			 "commands sometime before your next pull:\n"
+			 "\n"
+			 "  git config pull.rebase false  # merge (the default strategy)\n"
+			 "  git config pull.rebase true   # rebase\n"
+			 "  git config pull.ff only       # fast-forward only\n"
+			 "\n"
+			 "You can replace \"git config\" with \"git config --global\" to set a default\n"
+			 "preference for all repositories. You can also pass --rebase, --no-rebase,\n"
+			 "or --ff-only on the command line to override the configured default per\n"
+			 "invocation.\n"));
+	}
+
 	if (opt_rebase) {
 		int ret = 0;
 		int ran_ff = 0;
-- 
2.29.2

[PATCH v5 3/3] pull: display default warning only when non-ff

[Felipe Contreras]

There's no need to display the annoying warning on every pull... only
the ones that are not fast-forward.

This requires the tests to pick another base, so the merge is not
fast-forward. And in the cases where --ff-only is specified add
test_must_fail (since now they are non-fast-forward).

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 builtin/pull.c               |  7 +++++--
 t/t7601-merge-pull-config.sh | 28 +++++++++++++++++-----------
 2 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/builtin/pull.c b/builtin/pull.c
index ff8e3ce137..9a7caf3a3e 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -934,6 +934,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 	struct object_id orig_head, curr_head;
 	struct object_id rebase_fork_point;
 	int autostash;
+	int can_ff;
 
 	if (!getenv("GIT_REFLOG_ACTION"))
 		set_reflog_message(argc, argv);
@@ -1029,7 +1030,9 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 	if (opt_rebase && merge_heads.nr > 1)
 		die(_("Cannot rebase onto multiple branches."));
 
-	if (default_mode && opt_verbosity >= 0 && !opt_ff) {
+	can_ff = get_can_ff(&orig_head, &merge_heads.oid[0]);
+
+	if (default_mode && !can_ff && opt_verbosity >= 0 && !opt_ff) {
 		advise(_("Pulling without specifying how to reconcile divergent branches is\n"
 			 "discouraged. You can squelch this message by running one of the following\n"
 			 "commands sometime before your next pull:\n"
@@ -1058,7 +1061,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 		    submodule_touches_in_range(the_repository, &upstream, &curr_head))
 			die(_("cannot rebase with locally recorded submodule modifications"));
 		if (!autostash) {
-			if (get_can_ff(&orig_head, &merge_heads.oid[0])) {
+			if (can_ff) {
 				/* we can fast-forward this without invoking rebase */
 				opt_ff = "--ff-only";
 				ran_ff = 1;
diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
index 6774e9d86f..6b4adab8b1 100755
--- a/t/t7601-merge-pull-config.sh
+++ b/t/t7601-merge-pull-config.sh
@@ -28,7 +28,7 @@ test_expect_success 'setup' '
 '
 
 test_expect_success 'pull.rebase not set' '
-	git reset --hard c0 &&
+	git reset --hard c2 &&
 	git -c color.advice=always pull . c1 2>err &&
 	test_decode_color <err >decoded &&
 	test_i18ngrep "<YELLOW>hint: " decoded &&
@@ -36,54 +36,60 @@ test_expect_success 'pull.rebase not set' '
 
 '
 
-test_expect_success 'pull.rebase not set and pull.ff=true' '
+test_expect_success 'pull.rebase not set (fast-forward)' '
 	git reset --hard c0 &&
+	git pull . c1 2>err &&
+	test_i18ngrep ! "Pulling without specifying how to reconcile" err
+'
+
+test_expect_success 'pull.rebase not set and pull.ff=true' '
+	git reset --hard c2 &&
 	test_config pull.ff true &&
 	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and pull.ff=false' '
-	git reset --hard c0 &&
+	git reset --hard c2 &&
 	test_config pull.ff false &&
 	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and pull.ff=only' '
-	git reset --hard c0 &&
+	git reset --hard c2 &&
 	test_config pull.ff only &&
-	git pull . c1 2>err &&
+	test_must_fail git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --rebase given' '
-	git reset --hard c0 &&
+	git reset --hard c2 &&
 	git pull --rebase . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --no-rebase given' '
-	git reset --hard c0 &&
+	git reset --hard c2 &&
 	git pull --no-rebase . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --ff given' '
-	git reset --hard c0 &&
+	git reset --hard c2 &&
 	git pull --ff . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --no-ff given' '
-	git reset --hard c0 &&
+	git reset --hard c2 &&
 	git pull --no-ff . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --ff-only given' '
-	git reset --hard c0 &&
-	git pull --ff-only . c1 2>err &&
+	git reset --hard c2 &&
+	test_must_fail git pull --ff-only . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
-- 
2.29.2

Re: [PATCH v5 1/3] pull: refactor fast-forward check

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> It's much cleaner this way.

It is obvious that a focused single purpose helper with less
indentation is easier to follow both at the calling site and the
implementation itself.

"It's much cleaner" is not something you need to say.

If you were making it uglier, but other benefits outweigh the
ugliness, that may deserve to be said, but that is not the case
here.

> Also, we would like to be able to make this check before the decision to
> rebase is made.

... in a future step.

That is something we want to say upfront, not "Also".

The patch itself looks quite straightforward.

Thanks.

Re: [PATCH v5 2/3] pull: move default warning

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Eventually we want to be able to display the warning only when
> fast-forward merges are not possible.
>
> In order to do so we need to move the default warning up to the point
> where we can check if we can fast-forward or not.

Makes sense.

> Additionally, config_get_rebase() was probably never its true home.

I agree with this point.  I've always found it suboptimal.

> This requires a temporary variable to check if we are in the
> "default mode" (no --rebase or --no-rebase specified).

Two points:

 - "mode" is so overused a word; a more focused word is preferrable.

 - by introducing a local variable in cmd_pull() and passing a
   pointer to it to config_get_rebase(), we can easily avoid having
   to rely on an extra global variable.

I'd suggest addressing the above along the following lines.

   -static enum rebase_type config_get_rebase(void)
   +static enum rebase_type config_get_rebase(int *rebase_unspecified)
    {
   +        *rebase_unspecified = 0;

            ... various "return" of configured values ...

   +        *rebase_unspecified = 1;
            return REBASE_FALSE;
    }

Then the caller would declare

	int rebase_unspecified = 0;

and call 

	if (opt_rebase < 0)
		opt_rebase = config_get_rebase(&rebase_unspecified);

to possibly cause it to set to true, and use that instead of the
global variable to decide if we want to give the help text.  When
the helper is not called due to opt_rebase already being set, it is
not using configured value but using the choice from the command
line, so rebase_unspecified is still false after this point.

> @@ -1040,6 +1029,21 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
>  	if (opt_rebase && merge_heads.nr > 1)
>  		die(_("Cannot rebase onto multiple branches."));

And this is the point where we finish various error checks and
starts to run either rebase or merge.  It is as late as we could
delay the "non-ff and you are not configured" message.  In other
words, the place chosen in cmd_pull() to move this code to is
optimal.

> +	if (default_mode && opt_verbosity >= 0 && !opt_ff) {
> +		advise(_("Pulling without specifying how to reconcile divergent branches is\n"
> +			 "discouraged. You can squelch this message by running one of the following\n"
> +			 "commands sometime before your next pull:\n"
> +			 "\n"
> +			 "  git config pull.rebase false  # merge (the default strategy)\n"
> +			 "  git config pull.rebase true   # rebase\n"
> +			 "  git config pull.ff only       # fast-forward only\n"
> +			 "\n"
> +			 "You can replace \"git config\" with \"git config --global\" to set a default\n"
> +			 "preference for all repositories. You can also pass --rebase, --no-rebase,\n"
> +			 "or --ff-only on the command line to override the configured default per\n"
> +			 "invocation.\n"));
> +	}

Either as a part of this step, as a part of the next step, or a
separate follow-up patch, we should

 - create a single-purpose helper function that only calls advise()
   with the message and returns; name it show_advice_pull_non_ff().

 - correct the if() statement above, so that regardless of verbosity
   level, we can do _something_ common when the history does not
   fast-forward.  I.e.

	if (rebase_unspecified && !opt_ff) {
		if (opt_verbosity >= 0)
			show_advice_pull_non_ff();
	}

These would allow us to further turn the logic to

	if (rebase_unspecified && !opt_ff) {
		if (opt_verbosity >= 0 && advice_pull_non_ff)
			show_advice_pull_non_ff();
		die("not a fast-forward; must merge or rebase");
	}

later in the far future, and we do not want that die() to be
affected by verbosity settings.

I'll queue such a fix-up patch on top of the series before pushing
the integration results out on 'seen'.

Thanks.

Re: [PATCH v5 3/3] pull: display default warning only when non-ff

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> There's no need to display the annoying warning on every pull... only
> the ones that are not fast-forward.

Yes!  And thanks to the previous two steps, the change to the code
is quite obvious.  I don't have to give any further comment on the
part that changes code---it is well done, period.

> This requires the tests to pick another base, so the merge is not
> fast-forward. And in the cases where --ff-only is specified add
> test_must_fail (since now they are non-fast-forward).

I am not sure what this means.  

Existing tests pull histories that may or may not be descendants of
the HEAD.  If we do not change the pair of commits involved in the
tests, i.e. if we do not apply many s/c0/c2/ replacement I see in
the patch, some of these tests would change their behaviour with
respect to their advice output (but not the outcome).  The ones that
pulled fast-forward would stop showing the warning, and that is a
good effect of this change.  We want to see that in the update to
the tests, no?

The ones that pulled non-fast-forward history would still show the
warning as they used to, and that is also what we want to see after
this change.  Which means we want the tests to keep doing what they
do, while adjusting what we expect out of the tested commands to the
world that is made better with the code change in this patch.  I do
not think we need to add new tests to demonstrate the new behaviour,
as they (i.e. when the test pulls fast-forwardable history, with
various combinations of options and configuration) seem to be pretty
well covered already.

In other words, the changes the paragraph says that the commit made
to the tests sound quite backwards.

The actual changes to some of the tests do look sensible, testing
both sides of the coin.  I've looked at the changes to the tests,
but cannot convince me that we are not making irrelevant changes
to the tests, or losing coverage needlessly because of s/c0/c2/
(i.e. turning tests that used to check fast-forward situations
into tests that check non-ff situations).

> diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
> index 6774e9d86f..6b4adab8b1 100755
> --- a/t/t7601-merge-pull-config.sh
> +++ b/t/t7601-merge-pull-config.sh
> @@ -28,7 +28,7 @@ test_expect_success 'setup' '
>  '
>  
>  test_expect_success 'pull.rebase not set' '
> -	git reset --hard c0 &&
> +	git reset --hard c2 &&
>  	git -c color.advice=always pull . c1 2>err &&
>  	test_decode_color <err >decoded &&
>  	test_i18ngrep "<YELLOW>hint: " decoded &&

This is not "keeping what the original test does and adjusting the
expectation, to demonstrate how behaviour changed"; instead, we make
sure that the message we originally gave and we intend to keep
giving is shown in non-ff situation by choosing the current commit
that won't allow a ff merge.  This is OK if we did not lose test
coverage---as long as we test that we no longer give the message in
ff situation somewhere else, And that happens later, I think.

> @@ -36,54 +36,60 @@ test_expect_success 'pull.rebase not set' '
>  
>  '
>  
> -test_expect_success 'pull.rebase not set and pull.ff=true' '
> +test_expect_success 'pull.rebase not set (fast-forward)' '
>  	git reset --hard c0 &&
> +	git pull . c1 2>err &&
> +	test_i18ngrep ! "Pulling without specifying how to reconcile" err
> +'

This is the new test to check the other side of the coin.  It sees
how the original test to merge c1 into c0 would behave with the new
code.  We make sure we do not give the advice because it is
irrelevant in this situation.

So the above two are good, even though the way this patch updates
tests is probably a bit more error prone than necessary.

Since we have checked how the new code behave for fast-forward with
this new test, the remainder of the entire test script can be
modified to test only non-ff situation without losing test coverage?

I am not sure if that is the case.

> +test_expect_success 'pull.rebase not set and pull.ff=true' '
> +	git reset --hard c2 &&
>  	test_config pull.ff true &&
>  	git pull . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '

We are merely allowing fast-forward merges without unnecessary merge
commits, but we are faced to merge c1 into c2, which is not ff.  The
command goes ahead and merges anyway, but why shouldn't we be seeing
the message?  I am puzzled.

>  test_expect_success 'pull.rebase not set and pull.ff=false' '
> -	git reset --hard c0 &&
> +	git reset --hard c2 &&
>  	test_config pull.ff false &&
>  	git pull . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '
>  
>  test_expect_success 'pull.rebase not set and pull.ff=only' '
> -	git reset --hard c0 &&
> +	git reset --hard c2 &&
>  	test_config pull.ff only &&
> -	git pull . c1 2>err &&
> +	test_must_fail git pull . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '

This used to test that fast-forwarding the HEAD from c0 to c2 would
be done successfully without issuing the message.  Shouldn't that
still be true in the improved "do not complain on fast-forward" code?

We seem to be losing test coverage by checking how pull.ff=only prevents
the command from working in a non-ff merge.

I'd stop my review on the tests here, but I generally think s/c0/c2/
done in this patch is a wrong thing to do.  We are changing the
condition under which the messages is given (we are narrowing it to
avoid giving it when it is irrelevant), without changing the final
outcome (even though we changed the condition to give the message,
we didn't change what the final outcome of the pull command would
be), so I'd strongly prefer testing the same set of scenarios and
update the expectation to an improved reality.

>  test_expect_success 'pull.rebase not set and --rebase given' '
> -	git reset --hard c0 &&
> +	git reset --hard c2 &&
>  	git pull --rebase . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '
>  
>  test_expect_success 'pull.rebase not set and --no-rebase given' '
> -	git reset --hard c0 &&
> +	git reset --hard c2 &&
>  	git pull --no-rebase . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '
>  
>  test_expect_success 'pull.rebase not set and --ff given' '
> -	git reset --hard c0 &&
> +	git reset --hard c2 &&
>  	git pull --ff . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '
>  
>  test_expect_success 'pull.rebase not set and --no-ff given' '
> -	git reset --hard c0 &&
> +	git reset --hard c2 &&
>  	git pull --no-ff . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '
>  
>  test_expect_success 'pull.rebase not set and --ff-only given' '
> -	git reset --hard c0 &&
> -	git pull --ff-only . c1 2>err &&
> +	git reset --hard c2 &&
> +	test_must_fail git pull --ff-only . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '

Re: [PATCH v5 0/3] pull: stop warning on every pull

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> The discussion about making fast-forward-only pulls the default is
> stuck on mud, and there's no agreement about what we should even
> be warning our users about.

The above perception of yours is mostly due to misunderstanding, I
would have to say.  We are in agreement on what we should be warning
about at least, assuming that you are expressing what you want
clearly in the latest round of responses and I understood them
correctly [*1*].

I do not know if others on the list agree, though.

I do agree that there is no agreement on the behaviour in the
endgame.  In principle, I am in favor of disabling the more
dangerous half of the "git pull" command for those who haven't
configured anything.  But I can understand those who do not want
that behaviour, as the fallout would be quite big.

> Even my straightforward patches about improving documentation, and
> the consistency of the UI with --merge and other obvious fixes
> lost traction.

It may be obvious to you, but may not be to others on the list who
spoke in the thread and who didn't speak but read the discussion.

I did see potential goodness in the documentation update and that
was why I offered polishment on top of your patches in a v3 round,
but seeing the suggestions dismissed without convincing arguments
before v4 was sent out would have discouraged even the most patient
reviewers among us.  If you meant by "lost traction" the lack of
comments on v4, that was my reason for not commenting.

In any case, these three patches in this round looked quite sensible
to me, except for the tests in 3/3, and minor details of 2/3, both
of which I gave a more detailed review and suggestion.

Thanks.


[Footnote]

*1* The only difference between us is whether it is sensible to
allow explicitly ask to see the same behaviour as an unconfigured
user except for the help text---I do not think it is, and I do want
to avoid introducing pull.mode, but I've shown a way or two to get
the behaviour without adding pull.mode in the mix.

Re: [PATCH v5 2/3] pull: move default warning

[Felipe Contreras]

On Fri, Dec 11, 2020 at 12:54 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > Eventually we want to be able to display the warning only when
> > fast-forward merges are not possible.
> >
> > In order to do so we need to move the default warning up to the point
> > where we can check if we can fast-forward or not.
>
> Makes sense.
>
> > Additionally, config_get_rebase() was probably never its true home.
>
> I agree with this point.  I've always found it suboptimal.
>
> > This requires a temporary variable to check if we are in the
> > "default mode" (no --rebase or --no-rebase specified).
>
> Two points:
>
>  - "mode" is so overused a word; a more focused word is preferrable.

There's literally only one instance in the file, and it's a call to an
external function.

Plus, it refers to "git pull" without any --merge or --rebase (that's
the default mode in my book).

>  - by introducing a local variable in cmd_pull() and passing a
>    pointer to it to config_get_rebase(), we can easily avoid having
>    to rely on an extra global variable.
>
> I'd suggest addressing the above along the following lines.

...

> to possibly cause it to set to true, and use that instead of the
> global variable to decide if we want to give the help text.

Yeah, there's only 38 global variables. We wouldn't want another one
which makes the code pretty straightforward.

> > @@ -1040,6 +1029,21 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
> >       if (opt_rebase && merge_heads.nr > 1)
> >               die(_("Cannot rebase onto multiple branches."));
>
> And this is the point where we finish various error checks and
> starts to run either rebase or merge.  It is as late as we could
> delay the "non-ff and you are not configured" message.  In other
> words, the place chosen in cmd_pull() to move this code to is
> optimal.

Which is right before the fork between rebase and merge.

> > +     if (default_mode && opt_verbosity >= 0 && !opt_ff) {
> > +             advise(_("Pulling without specifying how to reconcile divergent branches is\n"
> > +                      "discouraged. You can squelch this message by running one of the following\n"
> > +                      "commands sometime before your next pull:\n"
> > +                      "\n"
> > +                      "  git config pull.rebase false  # merge (the default strategy)\n"
> > +                      "  git config pull.rebase true   # rebase\n"
> > +                      "  git config pull.ff only       # fast-forward only\n"
> > +                      "\n"
> > +                      "You can replace \"git config\" with \"git config --global\" to set a default\n"
> > +                      "preference for all repositories. You can also pass --rebase, --no-rebase,\n"
> > +                      "or --ff-only on the command line to override the configured default per\n"
> > +                      "invocation.\n"));
> > +     }
>
> Either as a part of this step, as a part of the next step, or a
> separate follow-up patch, we should
>
>  - create a single-purpose helper function that only calls advise()
>    with the message and returns; name it show_advice_pull_non_ff().

If we are going for low-hanging fruit there were many in v4 of this
series, which actually improve behavior, not just code organization,
but OK.

>  - correct the if() statement above, so that regardless of verbosity
>    level, we can do _something_ common when the history does not
>    fast-forward.  I.e.
>
>         if (rebase_unspecified && !opt_ff) {
>                 if (opt_verbosity >= 0)
>                         show_advice_pull_non_ff();
>         }
>
> These would allow us to further turn the logic to
>
>         if (rebase_unspecified && !opt_ff) {
>                 if (opt_verbosity >= 0 && advice_pull_non_ff)
>                         show_advice_pull_non_ff();
>                 die("not a fast-forward; must merge or rebase");
>         }

Should actually be something like:

        if (rebase_unspecified && !can_ff)
                die("Not a fast-forward; must either merge or rebase");

But yeah.

-- 
Felipe Contreras

Re: [PATCH v5 3/3] pull: display default warning only when non-ff

[Felipe Contreras]

On Fri, Dec 11, 2020 at 3:22 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > There's no need to display the annoying warning on every pull... only
> > the ones that are not fast-forward.
>
> Yes!  And thanks to the previous two steps, the change to the code
> is quite obvious.  I don't have to give any further comment on the
> part that changes code---it is well done, period.
>
> > This requires the tests to pick another base, so the merge is not
> > fast-forward. And in the cases where --ff-only is specified add
> > test_must_fail (since now they are non-fast-forward).
>
> I am not sure what this means.

It means in order to test the previous warning--which appeared in
fast-forward and non-fast-forward merges, and now appears only on
non-fast-forward merges--we need non-fast-forward merge situations.

> Existing tests pull histories that may or may not be descendants of
> the HEAD.  If we do not change the pair of commits involved in the
> tests, i.e. if we do not apply many s/c0/c2/ replacement I see in
> the patch, some of these tests would change their behaviour with
> respect to their advice output (but not the outcome).

All the tests, actually.

> The ones that
> pulled fast-forward would stop showing the warning, and that is a
> good effect of this change.  We want to see that in the update to
> the tests, no?

Yes.

> The ones that pulled non-fast-forward history would still show the
> warning as they used to, and that is also what we want to see after
> this change.

Currently no test is doing that; all are in a fast-forward situation.

> In other words, the changes the paragraph says that the commit made
> to the tests sound quite backwards.

I'm not sure how it is backwards. All the tests are fast-forward, we
need them not fast-forward, so we pick another base... so the merges
are not fast-forward.

> The actual changes to some of the tests do look sensible, testing
> both sides of the coin.  I've looked at the changes to the tests,
> but cannot convince me that we are not making irrelevant changes
> to the tests, or losing coverage needlessly because of s/c0/c2/
> (i.e. turning tests that used to check fast-forward situations
> into tests that check non-ff situations).

No test is checking fast-forward situations, because the warning
doesn't check fast-forward situations.

> > diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
> > index 6774e9d86f..6b4adab8b1 100755
> > --- a/t/t7601-merge-pull-config.sh
> > +++ b/t/t7601-merge-pull-config.sh
> > @@ -28,7 +28,7 @@ test_expect_success 'setup' '
> >  '
> >
> >  test_expect_success 'pull.rebase not set' '
> > -     git reset --hard c0 &&
> > +     git reset --hard c2 &&
> >       git -c color.advice=always pull . c1 2>err &&
> >       test_decode_color <err >decoded &&
> >       test_i18ngrep "<YELLOW>hint: " decoded &&
>
> This is not "keeping what the original test does and adjusting the
> expectation, to demonstrate how behaviour changed"; instead, we make
> sure that the message we originally gave and we intend to keep
> giving is shown in non-ff situation by choosing the current commit
> that won't allow a ff merge.  This is OK if we did not lose test
> coverage---as long as we test that we no longer give the message in
> ff situation somewhere else, And that happens later, I think.
>
> > @@ -36,54 +36,60 @@ test_expect_success 'pull.rebase not set' '
> >
> >  '
> >
> > -test_expect_success 'pull.rebase not set and pull.ff=true' '
> > +test_expect_success 'pull.rebase not set (fast-forward)' '
> >       git reset --hard c0 &&
> > +     git pull . c1 2>err &&
> > +     test_i18ngrep ! "Pulling without specifying how to reconcile" err
> > +'
>
> This is the new test to check the other side of the coin.  It sees
> how the original test to merge c1 into c0 would behave with the new
> code.  We make sure we do not give the advice because it is
> irrelevant in this situation.
>
> So the above two are good, even though the way this patch updates
> tests is probably a bit more error prone than necessary.

Any suggestions to make it less error prone are welcome.

> Since we have checked how the new code behave for fast-forward with
> this new test, the remainder of the entire test script can be
> modified to test only non-ff situation without losing test coverage?
>
> I am not sure if that is the case.

It is the case. That's what the patch does.

> > +test_expect_success 'pull.rebase not set and pull.ff=true' '
> > +     git reset --hard c2 &&
> >       test_config pull.ff true &&
> >       git pull . c1 2>err &&
> >       test_i18ngrep ! "Pulling without specifying how to reconcile" err
> >  '
>
> We are merely allowing fast-forward merges without unnecessary merge
> commits, but we are faced to merge c1 into c2, which is not ff.  The
> command goes ahead and merges anyway, but why shouldn't we be seeing
> the message?  I am puzzled.

Because that's what the current code does; it just checks that any
opt_ff is set, it doesn't check for any specific values.

I tried to fix that since v1, v2, v3, and v4 of the series [1], which
only received comments from Elijah Newren, but that's a separate
patch, and as I mentioned in the cover letter of v5; I've dropped all
those other patches.

> >  test_expect_success 'pull.rebase not set and pull.ff=false' '
> > -     git reset --hard c0 &&
> > +     git reset --hard c2 &&
> >       test_config pull.ff false &&
> >       git pull . c1 2>err &&
> >       test_i18ngrep ! "Pulling without specifying how to reconcile" err
> >  '
> >
> >  test_expect_success 'pull.rebase not set and pull.ff=only' '
> > -     git reset --hard c0 &&
> > +     git reset --hard c2 &&
> >       test_config pull.ff only &&
> > -     git pull . c1 2>err &&
> > +     test_must_fail git pull . c1 2>err &&
> >       test_i18ngrep ! "Pulling without specifying how to reconcile" err
> >  '
>
> This used to test that fast-forwarding the HEAD from c0 to c2 would
> be done successfully without issuing the message.  Shouldn't that
> still be true in the improved "do not complain on fast-forward" code?

No. It doesn't care if it's fast-forward or not; it's just checking
that "pull.ff=only" is set.

Before the code just checks "!opt_ff", now it checks "!opt_ff && !can_ff".

So, in order to do the "pull.ff=only" check, we need a non-fast-forward merge.

> We seem to be losing test coverage by checking how pull.ff=only prevents
> the command from working in a non-ff merge.

No we don't. Remove the "test_config pull.ff only" and the test fails,
as expected.

> I'd stop my review on the tests here, but I generally think s/c0/c2/
> done in this patch is a wrong thing to do.  We are changing the
> condition under which the messages is given (we are narrowing it to
> avoid giving it when it is irrelevant), without changing the final
> outcome (even though we changed the condition to give the message,
> we didn't change what the final outcome of the pull command would
> be), so I'd strongly prefer testing the same set of scenarios and
> update the expectation to an improved reality.

We are testing *exactly* the same test scenarios, we are just forcing
can_ff to be false.

If I remove the precise thing each test-case is supposed to test:

diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
index 6b4adab8b1..6c3413ddc9 100755
--- a/t/t7601-merge-pull-config.sh
+++ b/t/t7601-merge-pull-config.sh
@@ -44,52 +44,49 @@ test_expect_success 'pull.rebase not set (fast-forward)' '

 test_expect_success 'pull.rebase not set and pull.ff=true' '
  git reset --hard c2 &&
- test_config pull.ff true &&
  git pull . c1 2>err &&
  test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '

 test_expect_success 'pull.rebase not set and pull.ff=false' '
  git reset --hard c2 &&
- test_config pull.ff false &&
  git pull . c1 2>err &&
  test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '

 test_expect_success 'pull.rebase not set and pull.ff=only' '
  git reset --hard c2 &&
- test_config pull.ff only &&
- test_must_fail git pull . c1 2>err &&
+ git pull . c1 2>err &&
  test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '

 test_expect_success 'pull.rebase not set and --rebase given' '
  git reset --hard c2 &&
- git pull --rebase . c1 2>err &&
+ git pull . c1 2>err &&
  test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '

 test_expect_success 'pull.rebase not set and --no-rebase given' '
  git reset --hard c2 &&
- git pull --no-rebase . c1 2>err &&
+ git pull . c1 2>err &&
  test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '

 test_expect_success 'pull.rebase not set and --ff given' '
  git reset --hard c2 &&
- git pull --ff . c1 2>err &&
+ git pull . c1 2>err &&
  test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '

 test_expect_success 'pull.rebase not set and --no-ff given' '
  git reset --hard c2 &&
- git pull --no-ff . c1 2>err &&
+ git pull . c1 2>err &&
  test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '

 test_expect_success 'pull.rebase not set and --ff-only given' '
  git reset --hard c2 &&
- test_must_fail git pull --ff-only . c1 2>err &&
+ git pull . c1 2>err &&
  test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '

What do we get?

not ok 4 - pull.rebase not set and pull.ff=true
not ok 5 - pull.rebase not set and pull.ff=false
not ok 6 - pull.rebase not set and pull.ff=only
not ok 7 - pull.rebase not set and --rebase given
not ok 8 - pull.rebase not set and --no-rebase given
not ok 9 - pull.rebase not set and --ff given
not ok 10 - pull.rebase not set and --no-ff given
not ok 11 - pull.rebase not set and --ff-only given

All failures. Exactly as expected.

So what coverage precisely are we losing?

Cheers.

[1] https://lore.kernel.org/git/20201204061623.1170745-13-felipe.contreras@gmail.com/

-- 
Felipe Contreras

Re: [PATCH v5 0/3] pull: stop warning on every pull

[Felipe Contreras]

On Fri, Dec 11, 2020 at 5:22 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > The discussion about making fast-forward-only pulls the default is
> > stuck on mud, and there's no agreement about what we should even
> > be warning our users about.
>
> The above perception of yours is mostly due to misunderstanding, I
> would have to say.  We are in agreement on what we should be warning
> about at least, assuming that you are expressing what you want
> clearly in the latest round of responses and I understood them
> correctly [*1*].

I'm not trying to be difficult here, but at every round where you have
stated what it is that I want, it's not actually what I want, and the
last round is no exception, in my option.

Let's assume that I'm not explaining clearly what I want.

In the last round you said you wanted an error, not a warning. That's
not what I want; I'm proposing a warning.

But that's not what I was referring to here.

> I do not know if others on the list agree, though.

This is what I was referring to. Initially there seemed to be some
interest, and suddenly that interest disappeared.

> I do agree that there is no agreement on the behaviour in the
> endgame.

See? I disagree.

I think the endgame is clear. How we get there is where there's no agreement.

> In principle, I am in favor of disabling the more
> dangerous half of the "git pull" command for those who haven't
> configured anything.  But I can understand those who do not want
> that behaviour, as the fallout would be quite big.

And who is that? Did anyone in the list express that they did not want
that behavior?

> > Even my straightforward patches about improving documentation, and
> > the consistency of the UI with --merge and other obvious fixes
> > lost traction.
>
> It may be obvious to you, but may not be to others on the list who
> spoke in the thread and who didn't speak but read the discussion.
>
> I did see potential goodness in the documentation update and that
> was why I offered polishment on top of your patches in a v3 round,
> but seeing the suggestions dismissed without convincing arguments
> before v4 was sent out would have discouraged even the most patient
> reviewers among us.  If you meant by "lost traction" the lack of
> comments on v4, that was my reason for not commenting.

I did not dismiss your suggestions, I replied to your suggestions [1].
You did not reply back.

Moreover, in patch 2 I saw you had some confusion [2], in which you
said you didn't see any value in updating the message without changing
the condition that triggers, to which I replied [3]: "Maybe it will be
clearer when I send all the patches."

That's why I sent v4; not because I thought the review of v3 was done,
but because we were stuck not seeing the evolution of the warning.

In v4 I went through every step of the evolution [4], and I went back
to what I said in v3:

  At this point we can update the warning to mention that we are inside
  a non-fast-forward case. But it's not necessary.

So I did not dismiss the suggestion, I replied to it, and put a pin on it.

You can certainly bring the same suggestion in v4, but I seem to have
convinced Elijah Newren that "fast-forward" can be used as an adverb
perfectly well, and it in fact is, in many places in the documentation
both internal, and external.

> In any case, these three patches in this round looked quite sensible
> to me, except for the tests in 3/3, and minor details of 2/3, both
> of which I gave a more detailed review and suggestion.

Great.

That should improve the situation of most users. And also has the
added benefit that it's 3 less patches I have to carry around on every
round.

Cheers.

[1] https://lore.kernel.org/git/CAMP44s1ZDXzGfEqpTeiG=aGAYK40ebnBLQKAbA7KGtcePGARfw@mail.gmail.com/
[2] https://lore.kernel.org/git/xmqq4kkx9vzx.fsf@gitster.c.googlers.com/
[3] https://lore.kernel.org/git/CAMP44s1aYqzCVvELH8zULaTkOdgLSSAQ0LE8WfgQKLPfU2MHfg@mail.gmail.com/
[4] https://lore.kernel.org/git/CAMP44s2hUCd9qc83LReGyjy8N+u++eK6VjwGhDhrX0f0SbKmig@mail.gmail.com

-- 
Felipe Contreras

Re: [PATCH v5 3/3] pull: display default warning only when non-ff

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> We seem to be losing test coverage by checking how pull.ff=only prevents
>> the command from working in a non-ff merge.
>
> No we don't. Remove the "test_config pull.ff only" and the test fails,
> as expected.

> ...
> What do we get?
>
> not ok 4 - pull.rebase not set and pull.ff=true
> not ok 5 - pull.rebase not set and pull.ff=false
> not ok 6 - pull.rebase not set and pull.ff=only
> not ok 7 - pull.rebase not set and --rebase given
> not ok 8 - pull.rebase not set and --no-rebase given
> not ok 9 - pull.rebase not set and --ff given
> not ok 10 - pull.rebase not set and --no-ff given
> not ok 11 - pull.rebase not set and --ff-only given
>
> All failures. Exactly as expected.

Assuming only one kind of breakage and try to break exactly that
thing does not prove much.

I'll keep this short as I am supposed to be off officially.

With pulling without choosing between rebase/merge, the old code
had one behaviour wrt the message---it always advised, whether
the pull was ff or not.

The new code has two behaviour wrt this aspect.  It behaves
differently when the pull is ff or non-ff.  That would double the
possibility that needs to be tested if we wanted to keep covering
the original set of conditions *and* cover all new possibilities.

I am saying that you should keep the original ones, and add new ones
to cover the new cases if that matters.  Otherwise the conditions
under which the original tests were checking would no longer be
tested.

>  test_expect_success 'pull.rebase not set and --rebase given' '
> -	git reset --hard c0 &&
> +	git reset --hard c2 &&
>  	git pull --rebase . c1 2>err &&
>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>  '

This used to make sure an attempt to rebase c1 onto c0, which can be
fast-forwarded, would work fine, even though it used to give
warning.  We should keep testing the same condition.  The
expectation of seeing the warning is what must be changed, not the
test condition (i.e. rebasing c1 onto c2 instead of c0)---you are no
longer making sure that c1 can be rebased onto c0 cleanly.

Re: [PATCH v5 2/3] pull: move default warning

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>>  - correct the if() statement above, so that regardless of verbosity
>>    level, we can do _something_ common when the history does not
>>    fast-forward.  I.e.
>>
>>         if (rebase_unspecified && !opt_ff) {
>>                 if (opt_verbosity >= 0)
>>                         show_advice_pull_non_ff();
>>         }
>>
>> These would allow us to further turn the logic to
>>
>>         if (rebase_unspecified && !opt_ff) {
>>                 if (opt_verbosity >= 0 && advice_pull_non_ff)
>>                         show_advice_pull_non_ff();
>>                 die("not a fast-forward; must merge or rebase");
>>         }
>
> Should actually be something like:
>
>         if (rebase_unspecified && !can_ff)
>                 die("Not a fast-forward; must either merge or rebase");

The illustration I gave in the message you are responding to was
made in the context of patch 2/3; with patch 3/3 where can_ff
exists, it would not become like what you gave above.  It should
instead become

	if (rebase_unspecified && !opt_ff && !can_ff) {
		if (opt_verbosity >= 0 && advice_pull_non_ff)
			show_advice_pull_non_ff();
		die("not a fast-forward; must merge or rebase");
	}

i.e. when we can fast-forward, we do not trigger the "you must
specify rebase/merge" message, and we do not trigger the "not a
fast-forward" error.

Re: [PATCH v5 3/3] pull: display default warning only when non-ff

[Felipe Contreras]

On Fri, Dec 11, 2020 at 5:56 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> >> We seem to be losing test coverage by checking how pull.ff=only prevents
> >> the command from working in a non-ff merge.
> >
> > No we don't. Remove the "test_config pull.ff only" and the test fails,
> > as expected.
>
> > ...
> > What do we get?
> >
> > not ok 4 - pull.rebase not set and pull.ff=true
> > not ok 5 - pull.rebase not set and pull.ff=false
> > not ok 6 - pull.rebase not set and pull.ff=only
> > not ok 7 - pull.rebase not set and --rebase given
> > not ok 8 - pull.rebase not set and --no-rebase given
> > not ok 9 - pull.rebase not set and --ff given
> > not ok 10 - pull.rebase not set and --no-ff given
> > not ok 11 - pull.rebase not set and --ff-only given
> >
> > All failures. Exactly as expected.
>
> Assuming only one kind of breakage and try to break exactly that
> thing does not prove much.

It proves we are testing exactly the thing the test is meant to test.

No test is ever perfect.

> I'll keep this short as I am supposed to be off officially.

I appreciate that.

> With pulling without choosing between rebase/merge, the old code
> had one behaviour wrt the message---it always advised, whether
> the pull was ff or not.
>
> The new code has two behaviour wrt this aspect.  It behaves
> differently when the pull is ff or non-ff.  That would double the
> possibility that needs to be tested if we wanted to keep covering
> the original set of conditions *and* cover all new possibilities.
>
> I am saying that you should keep the original ones, and add new ones
> to cover the new cases if that matters.  Otherwise the conditions
> under which the original tests were checking would no longer be
> tested.

I disagree. The old condition is perfectly well tested with this test:

  test_expect_success 'pull.rebase not set' '
    git reset --hard c2 &&
    git -c color.advice=always pull . c1 2>err &&
    test_decode_color <err >decoded &&
    test_i18ngrep "<YELLOW>hint: " decoded &&
    test_i18ngrep "Pulling without specifying how to reconcile" decoded
  '

In other words; we have tests going horizontally, and tests going
vertically. That should cover all the bases.

But fine, if you want a matrix of tests I can do that.

> >  test_expect_success 'pull.rebase not set and --rebase given' '
> > -     git reset --hard c0 &&
> > +     git reset --hard c2 &&
> >       git pull --rebase . c1 2>err &&
> >       test_i18ngrep ! "Pulling without specifying how to reconcile" err
> >  '
>
> This used to make sure an attempt to rebase c1 onto c0, which can be
> fast-forwarded, would work fine,

No it didn't. It may very well have done a merge, or done nothing at all.

The tests that actually check that "git pull --rebase" works both in
the fast-forward and non-fast-forward are in t/t5520-pull.sh.

The goal of this particular test is to check that the warning is not there.

> even though it used to give
> warning.  We should keep testing the same condition.

We are testing what was originally tested: that the warning is not presented.

> The expectation of seeing the warning is what must be changed, not the
> test condition (i.e. rebasing c1 onto c2 instead of c0)---you are no
> longer making sure that c1 can be rebased onto c0 cleanly.

We disagree on what the "test condition" is supposed to be on this test.

But fine, I'll create the matrix.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v5 2/3] pull: move default warning

[Felipe Contreras]

On Fri, Dec 11, 2020 at 6:00 PM Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:

> > Should actually be something like:
> >
> >         if (rebase_unspecified && !can_ff)
> >                 die("Not a fast-forward; must either merge or rebase");
>
> The illustration I gave in the message you are responding to was
> made in the context of patch 2/3; with patch 3/3 where can_ff
> exists, it would not become like what you gave above.  It should
> instead become
>
>         if (rebase_unspecified && !opt_ff && !can_ff) {
>                 if (opt_verbosity >= 0 && advice_pull_non_ff)
>                         show_advice_pull_non_ff();
>                 die("not a fast-forward; must merge or rebase");
>         }
>
> i.e. when we can fast-forward, we do not trigger the "you must
> specify rebase/merge" message, and we do not trigger the "not a
> fast-forward" error.

It's not the !can_ff part I'm trying to highlight, it's the lack of
advice *after* we have decided to flip the switch.

As I said in another thread: I don't think we have any long
condescending error in any other command.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v5 3/3] pull: display default warning only when non-ff

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>>  test_expect_success 'pull.rebase not set and --rebase given' '
>> -	git reset --hard c0 &&
>> +	git reset --hard c2 &&
>>  	git pull --rebase . c1 2>err &&
>>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
>>  '
>
> This used to make sure an attempt to rebase c1 onto c0, which can be
> fast-forwarded, would work fine, even though it used to give
> warning.  We should keep testing the same condition.  The
> expectation of seeing the warning is what must be changed, not the
> test condition (i.e. rebasing c1 onto c2 instead of c0)---you are no
> longer making sure that c1 can be rebased onto c0 cleanly.

Let's try to explain it in a different way.

The original author of this test cared that pulling c1 with --rebase
into c0 succeeds, and that it does not give the error message.  We
have no right [*1*] to say that scenario (i.e. "pull --rebase" c1
into c0) no longer matters without a good justification.  And it is
not a good justification to say that the current code happens to
behave identically whether running "pull --rebase" of c1 into c0 or
c2 so it is sufficient to test the operation into c2.  The test is
*not* about how the current code happens to work.  It is to make
sure the scenarios test authors care about will keep behaving the
same way.

Some tests may be expecting that pulling c1 into c0 would issue the
message, and that the command succeeds, and with the patch 3/3 the
outcome may become different, i.e. the command succeeds without
annoying message.  That would break the expectation of the original
test authors, and it is a good thing.  By recording a change to the
expectation, we can document how the new behaviour works better under
the same scenario.


[Footnote]

*1* That does not mean we must not care about other scenarios that
are different from what have been tested with existing tests.  If
there is new behaviour introduced by patch 3/3, it is prudent to
protect it from future breakage by adding a test that pulls c1 into
c2, if that case is not already tested with existing tests.  

I suspect we already make sure a non-ff merge gives the annoying
message while going ahead, so there may be no new additional test
required, though.

Re: [PATCH v5 0/3] pull: stop warning on every pull

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> But that's not what I was referring to here.
>
>> I do not know if others on the list agree, though.
>
> This is what I was referring to. Initially there seemed to be some
> interest, and suddenly that interest disappeared.

Perhaps most of them are happy enough with the current behaviour.

Perhaps nobody cares strongly enough to say what they want to see,
as they fear that by speaking up they would be drawn into a
discussion that is needlessly hot and unpleasant.

>> I do agree that there is no agreement on the behaviour in the
>> endgame.
>
> See? I disagree.
>
> I think the endgame is clear. How we get there is where there's no agreement.

What you want as the endgame may be clear to you.

But I do not think there is clear concensus among people on the
list.

>> In principle, I am in favor of disabling the more
>> dangerous half of the "git pull" command for those who haven't
>> configured anything.  But I can understand those who do not want
>> that behaviour, as the fallout would be quite big.
>
> And who is that? Did anyone in the list express that they did not want
> that behavior?

I thought that you at least saw Dscho's reaction to the breakage
caused by "future" patch in response to one of the recent What's
cooking reports.  Doesn't that count "anyone on the list express"?

I am starting to feel myself that "don't do anything if this is not
a fast-forward" may be something that would have been great if we
had it from day one but is no longer a feasible default with
existing users, to be quite honest, so you can count my 20% as
another example.

Re: [PATCH v5 1/3] pull: refactor fast-forward check

[Felipe Contreras]

Hello,

Just to state that I'm not ignoring this feedback.

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > It's much cleaner this way.
> 
> It is obvious that a focused single purpose helper with less
> indentation is easier to follow both at the calling site and the
> implementation itself.

Yes, but the reader hasn't reached that point of the story yet.

> "It's much cleaner" is not something you need to say.

From the top of my head I can think of a few other reasons to refactor
code: a) it's more logical, b) it's less code, c) it's helps further
changes.

It's not necessary to say, but that's what I want to say; this reason,
and no other reason, is the main reason for this patch's existence.

> > Also, we would like to be able to make this check before the decision to
> > rebase is made.
> 
> ... in a future step.

Right.

It's not necessarily the case (could be an indeterminate future), but it
is the case in this patch series.

> That is something we want to say upfront, not "Also".

Not from my point of view. Even if it didn't help in future steps,
cleaning up code is generally desirable.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v5 3/3] pull: display default warning only when non-ff

[Felipe Contreras]

Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> >>  test_expect_success 'pull.rebase not set and --rebase given' '
> >> -	git reset --hard c0 &&
> >> +	git reset --hard c2 &&
> >>  	git pull --rebase . c1 2>err &&
> >>  	test_i18ngrep ! "Pulling without specifying how to reconcile" err
> >>  '
> >
> > This used to make sure an attempt to rebase c1 onto c0, which can be
> > fast-forwarded, would work fine, even though it used to give
> > warning.  We should keep testing the same condition.  The
> > expectation of seeing the warning is what must be changed, not the
> > test condition (i.e. rebasing c1 onto c2 instead of c0)---you are no
> > longer making sure that c1 can be rebased onto c0 cleanly.
> 
> Let's try to explain it in a different way.
> 
> The original author of this test cared that pulling c1 with --rebase
> into c0 succeeds, and that it does not give the error message.

I prefer not to attempt to read minds (plus, the author might have not
cared that the pulling succeeds), and anyway; that's not what matters.

What matters is the current situation, and the desired situation.

> We have no right [*1*] to say that scenario (i.e. "pull --rebase" c1
> into c0) no longer matters without a good justification.

But nobody is saying that. What I said is that in *this* particular
test-case that's not the objective of the test. And if you consider
hypothetical secondary objectives of the test, those are being tested
elsewhere.

> And it is not a good justification to say that the current code
> happens to behave identically whether running "pull --rebase" of c1
> into c0 or c2 so it is sufficient to test the operation into c2.  The
> test is *not* about how the current code happens to work.  It is to
> make sure the scenarios test authors care about will keep behaving the
> same way.

Again, I don't particularly care to mindread what the test authors might
have cared about.

It's clear from the tests themselves what they are trying to do: check
if the warning exists, or doesn't.

> Some tests may be expecting that pulling c1 into c0 would issue the
> message, and that the command succeeds, and with the patch 3/3 the
> outcome may become different, i.e. the command succeeds without
> annoying message.

No. All the tests (sans 1) check that the warning is *not* present.

If you do a fast-forward pull, the warning will not be present
(regardless of options), and the test would pass, but for the wrong
reasons.

> That would break the expectation of the original
> test authors, and it is a good thing.  By recording a change to the
> expectation, we can document how the new behaviour works better under
> the same scenario.

No, the expectation has not changed one iota; it's exactly same.

It's the reason for the same output that changed.

If I take the current tests, and I remove the thing that makes them
special (arguments and/or configuration), essentially making them all
"git pull":

@@ -35,52 +35,49 @@ test_expect_success 'pull.rebase not set' '
 
 test_expect_success 'pull.rebase not set and pull.ff=true' '
 	git reset --hard c0 &&
-	test_config pull.ff true &&
 	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and pull.ff=false' '
 	git reset --hard c0 &&
-	test_config pull.ff false &&
 	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and pull.ff=only' '
 	git reset --hard c0 &&
-	test_config pull.ff only &&
 	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --rebase given' '
 	git reset --hard c0 &&
-	git pull --rebase . c1 2>err &&
+	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --no-rebase given' '
 	git reset --hard c0 &&
-	git pull --no-rebase . c1 2>err &&
+	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --ff given' '
 	git reset --hard c0 &&
-	git pull --ff . c1 2>err &&
+	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --no-ff given' '
 	git reset --hard c0 &&
-	git pull --no-ff . c1 2>err &&
+	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
 test_expect_success 'pull.rebase not set and --ff-only given' '
 	git reset --hard c0 &&
-	git pull --ff-only . c1 2>err &&
+	git pull . c1 2>err &&
 	test_i18ngrep ! "Pulling without specifying how to reconcile" err
 '
 
What happens?

ok 3 - pull.rebase not set and pull.ff=true
ok 4 - pull.rebase not set and pull.ff=false
ok 5 - pull.rebase not set and pull.ff=only
ok 6 - pull.rebase not set and --rebase given
ok 7 - pull.rebase not set and --no-rebase given
ok 8 - pull.rebase not set and --ff given
ok 9 - pull.rebase not set and --no-ff given
ok 10 - pull.rebase not set and --ff-only given

They all pass. What are they supposed to be testing now? I don't know.

In my opinion they are no-ops now, but fine; I'll leave them as is.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v5 0/3] pull: stop warning on every pull

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > But that's not what I was referring to here.
> >
> >> I do not know if others on the list agree, though.
> >
> > This is what I was referring to. Initially there seemed to be some
> > interest, and suddenly that interest disappeared.
> 
> Perhaps most of them are happy enough with the current behaviour.

Or perhaps they are happhy enough the current behavior *for them*, but
not the other users.

> Perhaps nobody cares strongly enough to say what they want to see,
> as they fear that by speaking up they would be drawn into a
> discussion that is needlessly hot and unpleasant.

Or perhaps they got busy.

Or perhaps they got sick.

I don't see how listing hypotheticals is fruitful.

> >> I do agree that there is no agreement on the behaviour in the
> >> endgame.
> >
> > See? I disagree.
> >
> > I think the endgame is clear. How we get there is where there's no agreement.
> 
> What you want as the endgame may be clear to you.
> 
> But I do not think there is clear concensus among people on the
> list.

I do. It has been clear for many years.

> >> In principle, I am in favor of disabling the more
> >> dangerous half of the "git pull" command for those who haven't
> >> configured anything.  But I can understand those who do not want
> >> that behaviour, as the fallout would be quite big.
> >
> > And who is that? Did anyone in the list express that they did not want
> > that behavior?
> 
> I thought that you at least saw Dscho's reaction to the breakage
> caused by "future" patch in response to one of the recent What's
> cooking reports.

Yes, I saw it, but it was a complaint about the breakage of test due to
the merge of a patch that wasn't meant to be merged today.

> Doesn't that count "anyone on the list express"?

No. These are two different statements.

 1. This will break things for *me*
 2. This is a bad thing for *everyone*

These two statements have a different object. Also, the first doesn't
necessarily require rationale, we can take his word for it. But the
second one does.

It's not enough to say "I think this patch is bad for everyone"; you
have to explain *why*. I'd be happy to discuss with him his rationale,
which he hasn't given.

Moreover, isn't Schindelin advocating for a change that will cause
breakage (renaming the master branch).

> I am starting to feel myself that "don't do anything if this is not
> a fast-forward" may be something that would have been great if we
> had it from day one but is no longer a feasible default with
> existing users, to be quite honest, so you can count my 20% as
> another example.

As opposed to virtually everyone in this mailing list that has given an
opinion about the topic in the last 10 years (including you I count 3
out of literally dozens).

I will do some mail archeology and present the results.

Anyway, this is not relevant today, because you were the one that
proposed to go straight to an error.

What I propose for today is to introduce the option
"pull.mode=fast-forward", and improve the warning. Not an error.

That doesn't break the behavior for anyone, including Schindelin.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v5 2/3] pull: move default warning

[Felipe Contreras]

Felipe Contreras wrote:
> On Fri, Dec 11, 2020 at 12:54 AM Junio C Hamano <gitster@pobox.com> wrote:

> >  - by introducing a local variable in cmd_pull() and passing a
> >    pointer to it to config_get_rebase(), we can easily avoid having
> >    to rely on an extra global variable.
> >
> > I'd suggest addressing the above along the following lines.
> 
> ...
> 
> > to possibly cause it to set to true, and use that instead of the
> > global variable to decide if we want to give the help text.
> 
> Yeah, there's only 38 global variables. We wouldn't want another one
> which makes the code pretty straightforward.

Another thing that I mentioned in another version of the patch series
but not on this one (since the relevant patch was removed) is that this
variable is only needed temporarily; it can be removed by further code
reorganization.

So, I don't think it makes sense to change more code than necessary for
the sake of this variable (that might very well disappear).

-- 
Felipe Contreras

Re: [PATCH v5 2/3] pull: move default warning

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Fri, Dec 11, 2020 at 6:00 PM Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> > Should actually be something like:
>> >
>> >         if (rebase_unspecified && !can_ff)
>> >                 die("Not a fast-forward; must either merge or rebase");
>>
>> The illustration I gave in the message you are responding to was
>> made in the context of patch 2/3; with patch 3/3 where can_ff
>> exists, it would not become like what you gave above.  It should
>> instead become
>>
>>         if (rebase_unspecified && !opt_ff && !can_ff) {
>>                 if (opt_verbosity >= 0 && advice_pull_non_ff)
>>                         show_advice_pull_non_ff();
>>                 die("not a fast-forward; must merge or rebase");
>>         }
>>
>> i.e. when we can fast-forward, we do not trigger the "you must
>> specify rebase/merge" message, and we do not trigger the "not a
>> fast-forward" error.
>
> It's not the !can_ff part I'm trying to highlight, it's the lack of
> advice *after* we have decided to flip the switch.
>
> As I said in another thread: I don't think we have any long
> condescending error in any other command.

Only the "not a fast-forward and you must choose between merge and
rebase" part (i.e. what I listed as the first part of three-part
message) is the error.

The rest, the message that teaches how to choose between merge and
rebase from command line and configuration (or how to choose
permanently not to make the choice between the two), is not an
error---it's called advice.

Even if we were to introduce the third choice (i.e. permanently not
to choose between rebase or merge and instead just error out without
getting advice), the advice must stay for those who didn't make any
choice among the three (i.e. merge, rebase or ff-only).

We have many of them.  An easy example to spot is a similar sized
onefor "git checkout HEAD^0".  Neither that one or the one under
discussion is particularly condescending.

Re: [PATCH v5 0/3] pull: stop warning on every pull

[Felipe Contreras]

On Sat, Dec 12, 2020 at 10:36 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Junio C Hamano wrote:

> > I am starting to feel myself that "don't do anything if this is not
> > a fast-forward" may be something that would have been great if we
> > had it from day one but is no longer a feasible default with
> > existing users, to be quite honest, so you can count my 20% as
> > another example.
>
> As opposed to virtually everyone in this mailing list that has given an
> opinion about the topic in the last 10 years (including you I count 3
> out of literally dozens).

A quick update after reading a great deal of mails.

The only person I counted in 2013 that was against changing the
default is Matthieu Moy, and reading back what he said, even him was
in favor of adding a configuration for the new mode [1]. What he was
against was making it the default, and adding a warning stating it
would be the default.

Fortunately my patches introduce the mode [2] without making it
necessarily the default (we don't even have to change the warning and
say it will be changed in the future [3]).

So *nobody* was against the introduction of such mode.

Also, after reading the input from GitHub trainers, which Jeff
provided [4], perhaps leaving the default as "merge" makes sense. Our
curse of knowledge may bias us into thinking the user knows what a
rebase is. Maybe a permanent advice warning is the way to go, I'm
still mulling it over.

> Anyway, this is not relevant today, because you were the one that
> proposed to go straight to an error.
>
> What I propose for today is to introduce the option
> "pull.mode=fast-forward", and improve the warning. Not an error.
>
> That doesn't break the behavior for anyone, including Schindelin.

This is still true. We don't lose anything by introducing the mode.

We can make the decision to flip the default later (or not).

Cheers.

[1] https://lore.kernel.org/git/vpqbo41lo2v.fsf@anie.imag.fr/
[2] https://lore.kernel.org/git/20201208002648.1370414-18-felipe.contreras@gmail.com/
[3] https://lore.kernel.org/git/20201208002648.1370414-19-felipe.contreras@gmail.com/
[4] https://lore.kernel.org/git/20130909201751.GA14437@sigill.intra.peff.net/

-- 
Felipe Contreras

Re: [PATCH v5 2/3] pull: move default warning

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > On Fri, Dec 11, 2020 at 6:00 PM Junio C Hamano <gitster@pobox.com> wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >
> >> > Should actually be something like:
> >> >
> >> >         if (rebase_unspecified && !can_ff)
> >> >                 die("Not a fast-forward; must either merge or rebase");
> >>
> >> The illustration I gave in the message you are responding to was
> >> made in the context of patch 2/3; with patch 3/3 where can_ff
> >> exists, it would not become like what you gave above.  It should
> >> instead become
> >>
> >>         if (rebase_unspecified && !opt_ff && !can_ff) {
> >>                 if (opt_verbosity >= 0 && advice_pull_non_ff)
> >>                         show_advice_pull_non_ff();
> >>                 die("not a fast-forward; must merge or rebase");
> >>         }
> >>
> >> i.e. when we can fast-forward, we do not trigger the "you must
> >> specify rebase/merge" message, and we do not trigger the "not a
> >> fast-forward" error.
> >
> > It's not the !can_ff part I'm trying to highlight, it's the lack of
> > advice *after* we have decided to flip the switch.
> >
> > As I said in another thread: I don't think we have any long
> > condescending error in any other command.
> 
> Only the "not a fast-forward and you must choose between merge and
> rebase" part (i.e. what I listed as the first part of three-part
> message) is the error.
> 
> The rest, the message that teaches how to choose between merge and
> rebase from command line and configuration (or how to choose
> permanently not to make the choice between the two), is not an
> error---it's called advice.

Right. After re-reading the 2013 discussion, and the GitHub trainers'
input that Jeff King shared with us [1], it might make sense to
eventually keep this advice (permanently), since many users might not
know what a rebase is, and would not want to know at this point of their
learning curve.

That being said, the advice still needs to be improved, and I have
already yet another version taking this into consideration ready to be
sent. Just waiting for feedback on the previous can_ff series.

> Even if we were to introduce the third choice (i.e. permanently not
> to choose between rebase or merge and instead just error out without
> getting advice), the advice must stay for those who didn't make any
> choice among the three (i.e. merge, rebase or ff-only).

With the introduction of such mode, and the permanent advice, we would
have:

  if (!can_ff) {
	  if (!mode && opt_verbosity >= 0 && advice_pull_non_ff)
		  show_advice_pull_non_ff();

	  if (mode == PULL_MODE_FF_ONLY)
		  die(_("Not a fast-forward, either merge or rebase.\n"));
  }

If in the future we decide to make it the default, we would have:

  if (!can_ff) {
	  if (!mode && opt_verbosity >= 0 && advice_pull_non_ff)
		  show_advice_pull_non_ff();

	  if (!mode || mode == PULL_MODE_FF_ONLY)
		  die(_("Not a fast-forward, either merge or rebase.\n"));
  }

The transition is very straightforward.

> We have many of them.  An easy example to spot is a similar sized
> onefor "git checkout HEAD^0".  Neither that one or the one under
> discussion is particularly condescending.

I am not familiar with these "advices", since I basically ignore them,
and they are not presented to me in any different color, or special
presentation. I generally ignore textwalls in my command line.

But fine, if these walls of text already exist, perhaps it makes sense
to have yet another permanent one (just with better text, and better
options).

With an improved advice--which includes an option that is good enough we
*can* make the default (pull.mode=ff-only)--perhaps that would be
enough, and in a couple of years we can make the assessment if it's
enough or not.

But clearly *today* we don't have such mode, which people have found
missing for more than a decadte.

Cheers.

[1] https://lore.kernel.org/git/20130909201751.GA14437@sigill.intra.peff.net/

-- 
Felipe Contreras

Re: [PATCH v5 3/3] pull: display default warning only when non-ff

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> The original author of this test cared that pulling c1 with --rebase
>> into c0 succeeds, and that it does not give the error message.
>
> I prefer not to attempt to read minds (plus, the author might have not
> cared that the pulling succeeds), and anyway; that's not what matters.
> ...
> Again, I don't particularly care to mindread what the test authors might
> have cared about.

You do not have to read mind.  What is written in the test is clear
enough: run "git pull --rebase . c1" into c0 and see what happens.

Re: [PATCH v5 3/3] pull: display default warning only when non-ff

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> >> The original author of this test cared that pulling c1 with --rebase
> >> into c0 succeeds, and that it does not give the error message.
> >
> > I prefer not to attempt to read minds (plus, the author might have not
> > cared that the pulling succeeds), and anyway; that's not what matters.
> > ...
> > Again, I don't particularly care to mindread what the test authors might
> > have cared about.
> 
> You do not have to read mind.  What is written in the test is clear
> enough: run "git pull --rebase . c1" into c0 and see what happens.

That is precisely my point: it is written in the test, no mindreading
neccessary.

-- 
Felipe Contreras

[PATCH v5 2/3] pull: move default warning

[Felipe Contreras]

Eventually we want to be able to display the warning only when
fast-forward merges are not possible.

In order to do so, we need to move the default warning up to the point
where we can check if we can fast-forward or not.

Additionally, config_get_rebase() was probably never its true home.

This requires a temporary variable to check if we are in the
"default mode" (no --rebase or --no-rebase specified). But this variable
can be removed later on with further code reorganization.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 builtin/pull.c | 32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/builtin/pull.c b/builtin/pull.c
index 03e6d53243..ff8e3ce137 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -27,6 +27,8 @@
 #include "commit-reach.h"
 #include "sequencer.h"
 
+static int default_mode;
+
 /**
  * Parses the value of --rebase. If value is a false value, returns
  * REBASE_FALSE. If value is a true value, returns REBASE_TRUE. If value is
@@ -344,20 +346,7 @@ static enum rebase_type config_get_rebase(void)
 	if (!git_config_get_value("pull.rebase", &value))
 		return parse_config_rebase("pull.rebase", value, 1);
 
-	if (opt_verbosity >= 0 && !opt_ff) {
-		advise(_("Pulling without specifying how to reconcile divergent branches is\n"
-			 "discouraged. You can squelch this message by running one of the following\n"
-			 "commands sometime before your next pull:\n"
-			 "\n"
-			 "  git config pull.rebase false  # merge (the default strategy)\n"
-			 "  git config pull.rebase true   # rebase\n"
-			 "  git config pull.ff only       # fast-forward only\n"
-			 "\n"
-			 "You can replace \"git config\" with \"git config --global\" to set a default\n"
-			 "preference for all repositories. You can also pass --rebase, --no-rebase,\n"
-			 "or --ff-only on the command line to override the configured default per\n"
-			 "invocation.\n"));
-	}
+	default_mode = 1;
 
 	return REBASE_FALSE;
 }
@@ -1040,6 +1029,21 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
 	if (opt_rebase && merge_heads.nr > 1)
 		die(_("Cannot rebase onto multiple branches."));
 
+	if (default_mode && opt_verbosity >= 0 && !opt_ff) {
+		advise(_("Pulling without specifying how to reconcile divergent branches is\n"
+			 "discouraged. You can squelch this message by running one of the following\n"
+			 "commands sometime before your next pull:\n"
+			 "\n"
+			 "  git config pull.rebase false  # merge (the default strategy)\n"
+			 "  git config pull.rebase true   # rebase\n"
+			 "  git config pull.ff only       # fast-forward only\n"
+			 "\n"
+			 "You can replace \"git config\" with \"git config --global\" to set a default\n"
+			 "preference for all repositories. You can also pass --rebase, --no-rebase,\n"
+			 "or --ff-only on the command line to override the configured default per\n"
+			 "invocation.\n"));
+	}
+
 	if (opt_rebase) {
 		int ret = 0;
 		int ran_ff = 0;
-- 
2.29.2