Re: [PATCH 1/9] t7601: add relative precedence tests for merge and rebase flags/options

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 20, 2021, 18:22 UTC
Message-ID: <xmqq35s8j15h.fsf@gitster.g>
In-Reply-To: <CABPp-BFMHhxgaLnA+gLHJENVfzVv6j2Ax4G6y+XsrU3wBJq6rQ@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 11 quoted lines

>> OK.  These all ensure that when the history does not fast-forward,
>> the command will fail when --ff-only tells us to allow only
>> fast-forward.  I am not sure "takes precedence" is a meaningful
>> label, though.  It is more like "ff-only means ff-only and fails
>> when the upstream history is not a descendant, no matter how the
>> possible integration is set to be performed".
>
> So, I think you're saying you view fast-forwards as a subset of valid
> rebases (and fast-forwards are also a subset of valid rmerges), and
> thus you view --ff-only --rebase as an instruction to only proceed if
> both command line flags can be satisfied.

Ah, I didn't think of it myself, but now you put it in these words, I do agree that the view makes sense. When we have nothing of our own, a degenerated form of a rebase is a fast-forward, even more so than a fast-forward being a degenerated form of a merge.

> That makes sense, but I don't know how to put that into a test
> description that isn't ridiculously long.

Me neither.  Let's not waste too much brain-cycles over this.

Thanks.