diff options
author | Elijah Newren <newren@gmail.com> | 2020-02-15 21:36:31 (GMT) |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2020-02-16 23:40:42 (GMT) |
commit | befb89ce7c43a0bd0de11909951dd3015874e9db (patch) | |
tree | 06cdb3a48fa78ec38964e9321d1f5fd08c9a9f83 /help.c | |
parent | 9a70f3d4ae673e02e78b1061fcc8fc01bc8d9276 (diff) | |
download | git-befb89ce7c43a0bd0de11909951dd3015874e9db.zip git-befb89ce7c43a0bd0de11909951dd3015874e9db.tar.gz git-befb89ce7c43a0bd0de11909951dd3015874e9db.tar.bz2 |
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 'help.c')
0 files changed, 0 insertions, 0 deletions