rebase: fast-forward --fork-point in more cases
Before, when we rebased with a --fork-point invocation where the
fork-point wasn't empty, we would be setting options.restrict_revision.
The fast-forward logic would automatically declare that the rebase was
not fast-forwardable if it was set. However, this was painting with a
very broad brush.
Refine the logic so that we can fast-forward in the case where the
restricted revision is equal to the merge base, since we stop rebasing
at the merge base anyway.
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 1e1406c..7ef9095 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -1261,6 +1261,7 @@ static int is_linear_history(struct commit *from, struct commit *to)
}
static int can_fast_forward(struct commit *onto, struct commit *upstream,
+ struct commit *restrict_revision,
struct object_id *head_oid, struct object_id *merge_base)
{
struct commit *head = lookup_commit(the_repository, head_oid);
@@ -1280,6 +1281,9 @@ static int can_fast_forward(struct commit *onto, struct commit *upstream,
if (!oideq(merge_base, &onto->object.oid))
goto done;
+ if (restrict_revision && !oideq(&restrict_revision->object.oid, merge_base))
+ goto done;
+
if (!upstream)
goto done;
@@ -2042,9 +2046,9 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
* with new commits recreated by replaying their changes. This
* optimization must not be done if this is an interactive rebase.
*/
- if (can_fast_forward(options.onto, options.upstream, &options.orig_head,
- &merge_base) &&
- !is_interactive(&options) && !options.restrict_revision) {
+ if (can_fast_forward(options.onto, options.upstream, options.restrict_revision,
+ &options.orig_head, &merge_base) &&
+ !is_interactive(&options)) {
int flag;
if (!(options.flags & REBASE_FORCE)) {
