From: Elijah Newren <newren@xxxxxxxxx>
There are both merge and rebase branches in the logic, and previously
both had to handle fast-forwarding. Merge handled that implicitly
(because git merge handles it directly), while in rebase it was
explicit. Given that the --ff-only flag is meant to override any
--rebase or --no-rebase, make the code reflect that by handling
--ff-only before the merge-vs-rebase logic.
No functional changes, just making it easier to verify that the codeflow
matches our precedence rules.
Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
---
builtin/pull.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/builtin/pull.c b/builtin/pull.c
index d9796604825..5c9cbea37c9 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -1046,15 +1046,16 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
can_ff = get_can_ff(&orig_head, &merge_heads.oid[0]);
- if (!can_ff) {
- if (opt_ff) {
- if (!strcmp(opt_ff, "--ff-only"))
- die_ff_impossible();
- } else {
- if (rebase_unspecified && opt_verbosity >= 0)
- show_advice_pull_non_ff();
- }
+ /* ff-only takes precedence over rebase */
+ if (opt_ff && !strcmp(opt_ff, "--ff-only")) {
+ if (!can_ff)
+ die_ff_impossible();
+ else
+ return run_merge();
}
+ /* If no action specified and we can't fast forward, then warn. */
+ if (!opt_ff && rebase_unspecified && !can_ff)
+ show_advice_pull_non_ff();
if (opt_rebase) {
int ret = 0;
--
gitgitgadget
