RE: [PATCH v7 0/5] making pull advice not to trigger when unneeded

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Dec 15, 2020, 06:30 UTC
Message-ID: <5fd85811c3a6_d7c48208aa@natae.notmuch>
In-Reply-To: <20201214202647.3340193-1-gitster@pobox.com>

Junio C Hamano wrote:

Show 18 quoted lines

> Just to show what was pushed out on 'seen' while I was cutting the
> preview release...
> 
> This is based on Felipe's v6 (which was mislabled as v5 but sent on
> a different day from the true v5), with two clean-up commits
> inserted between Felipe's second step (now 2/5) and the third step
> (now 5/5, with necessary adjustments).
> 
> Even with the "correct condition" clean-up, I am not quite happy
> with the clarity of the logic around there.
> 
> I think !opt_ff does not exactly belong to the condition, if we
> consider that the eventual endgame should be to stop non-ff
> operation without merge or rebase by default with an error, and that
> should happen in this block.  The error message there should say
> "unable to fast-forward; must merge or rebase", which should equally
> apply to those who gave "--ff-only" explicitly, even though they may
> not need the advice message.

Agreed. Additionally it doesn't make sense that --ff skips the warning entirely, even though the user has not specified a merge or a rebase (as you yourself noted in a review of the test cases).

Show 10 quoted lines

> To avoid the ugly-looking "strcmp()" in the above, we may need to
> adjust "--ff" (fast-forward without creating an extra merge commit)
> and "--no-ff" (create an extra merge commit when the history could
> be fast-forwarded) to imply "merge", though.  It would automatically
> make rebase_unspecified would become false.  With such a tweak, we
> can then simplify it further to
> 
> -	if (rebase_unspecified && !can_ff &&
> -	    (!opt_ff || !strcmp("--ff-only", opt_ff))) {
> +	if (rebase_unspecified && !can_ff) {

Currently this is a rebase:

  git pull --rebase --ff

With your proposed change it would be an implied merge. I think it makes sense, but it's still a change in behavior.

This patch should do the trick:

--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -973,6 +973,11 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
        if (opt_rebase < 0)
                opt_rebase = config_get_rebase(&rebase_unspecified);
 
+       if (opt_ff && (!strcmp(opt_ff, "--ff") || !strcmp(opt_ff, "--no-ff"))) {
+               opt_rebase = 0;
+               rebase_unspecified = 0;
+       }
+
        if (read_cache_unmerged())
                die_resolve_conflict("pull");
 
Or do you mean --ff doesn't override --rebase? Therefore it's more of an
internal conceptual change.

-- 
Felipe Contreras