summaryrefslogtreecommitdiff
path: root/t/t4013
diff options
context:
space:
mode:
authorLibravatar Elijah Newren <newren@gmail.com>2020-02-15 21:36:31 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-02-16 15:40:42 -0800
commitbefb89ce7c43a0bd0de11909951dd3015874e9db (patch)
tree06cdb3a48fa78ec38964e9321d1f5fd08c9a9f83 /t/t4013
parentt3432: make these tests work with either am or merge backends (diff)
downloadtgif-befb89ce7c43a0bd0de11909951dd3015874e9db.tar.xz
rebase: allow more types of rebases to fast-forward
In the past, we dis-allowed rebases using the interactive backend from performing a fast-forward to short-circuit the rebase operation. This made sense for explicitly interactive rebases and some implicitly interactive rebases, but certainly became overly stringent when the merge backend was re-implemented via the interactive backend. Just as the am-based rebase has always had to disable the fast-forward based on a variety of conditions or flags (e.g. --signoff, --whitespace, etc.), we need to do the same but now with a few more options. However, continuing to use REBASE_FORCE for tracking this is problematic because the interactive backend used it for a different purpose. (When REBASE_FORCE wasn't set, the interactive backend would not fast-forward the whole series but would fast-forward individual "pick" commits at the beginning of the todo list, and then a squash or something would cause it to start generating new commits.) So, introduce a new allow_preemptive_ff flag contained within cmd_rebase() and use it to track whether we are going to allow a pre-emptive fast-forward that short-circuits the whole rebase. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4013')
0 files changed, 0 insertions, 0 deletions