git/builtin/pull.c, branch v2.33.6

pull: fix handling of multiple heads

2021-07-22T18:54:30Z

With multiple heads, we should not allow rebasing or fast-forwarding. Make sure any fast-forward request calls out specifically the fact that multiple branches are in play. Also, since we cannot fast-forward to multiple branches, fix our computation of can_ff. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

pull: update docs & code for option compatibility with rebasing

2021-07-22T18:54:30Z

git-pull.txt includes merge-options.txt, which is written assuming merges will happen. git-pull has allowed rebases for many years; update the documentation to reflect that. While at it, pass any `--signoff` flag through to the rebase backend too so that we don't have to document it as merge-specific. Rebase has supported the --signoff flag for years now as well. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

pull: abort by default when fast-forwarding is not possible

2021-07-22T18:54:29Z

We have for some time shown a long warning when the user does not specify how to reconcile divergent branches with git pull. Make it an error now. Initial-patch-by: Alex Henrie Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

pull: make --rebase and --no-rebase override pull.ff=only

2021-07-22T18:54:29Z

Fix the last few precedence tests failing in t7601 by now implementing the logic to have --[no-]rebase override a pull.ff=only config setting. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

pull: since --ff-only overrides, handle it first

2021-07-22T18:54:29Z

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. It turns out that this also fixes a bug for submodules. Previously, when --ff-only was given, the code would run `merge --ff-only` on the main module, and then run `submodule update --recursive --rebase` on the submodules. With this change, we still run `merge --ff-only` on the main module, but now run `submodule update --recursive --checkout` on the submodules. I believe this better reflects the intent of --ff-only to have it apply to both the main module and the submodules. (Sidenote: It is somewhat interesting that all merges pass `--checkout` to submodule update, even when `--no-ff` is specified, meaning that it will only do fast-forward merges for submodules. This was discussed in commit a6d7eb2c7a ("pull: optionally rebase submodules (remote submodule changes only)", 2017-06-23). The same limitations apply now as then, so we are not trying to fix this at this time.) Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

pull: abort if --ff-only is given and fast-forwarding is impossible

2021-07-21T04:43:12Z

The warning about pulling without specifying how to reconcile divergent branches says that after setting pull.rebase to true, --ff-only can still be passed on the command line to require a fast-forward. Make that actually work. Signed-off-by: Alex Henrie [en: updated tests; note 3 fixes and 1 new failure] Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

pull: trivial whitespace style fix

2021-06-19T07:36:17Z

Two spaces unaligned to anything is not part of the coding-style. A single tab is. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

pull: trivial cleanup

2021-06-19T07:36:17Z

There's no need to store ran_ff. Now it's obvious from the conditionals. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

pull: cleanup autostash check

2021-06-19T07:36:16Z

Currently "git pull --rebase" takes a shortcut in the case a fast-forward merge is possible; run_merge() is called with --ff-only. However, "git merge" didn't have an --autostash option, so, when "git pull --rebase --autostash" was called *and* the fast-forward merge shortcut was taken, then the pull failed. This was fixed in commit f15e7cf5cc (pull: ff --rebase --autostash works in dirty repo, 2017-06-01) by simply skipping the fast-forward merge shortcut. Later on "git merge" learned the --autostash option [a03b55530a (merge: teach --autostash option, 2020-04-07)], and so did "git pull" [d9f15d37f1 (pull: pass --autostash to merge, 2020-04-07)]. Therefore it's not necessary to skip the fast-forward merge shortcut anymore when called with --rebase --autostash. Let's always take the fast-forward merge shortcut by essentially reverting f15e7cf5cc. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

pull: display default warning only when non-ff

2020-12-16T01:39:42Z

There's no need to display the annoying warning on every pull... only the ones that are not fast-forward. The current warning tests still pass, but not because of the arguments or the configuration, but because they are all fast-forward. We need to test non-fast-forward situations now. Suggestions-by: Junio C Hamano Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano