git/builtin/pull.c, branch gitk-resize-error

fetch/pull: use the sparse index

2021-12-22T19:42:39Z

The 'git fetch' and 'git pull' commands parse the index in order to determine if submodules exist. Without command_requires_full_index=0, this will expand a sparse index, causing slow performance even when there is no new data to fetch. The .gitmodules file will never be inside a sparse directory entry, and even if it was, the index_name_pos() method would expand the sparse index if needed as we search for the path by name. These commands do not iterate over the index, which is the typical thing we are careful about when integrating with the sparse index. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

Merge branch 'ah/advice-pull-has-no-preference-between-rebase-and-merge'

2021-12-10T22:35:09Z

The advice message given by "git pull" when the user hasn't made a choice between merge and rebase still said that the merge is the default, which no longer is the case. This has been corrected. * ah/advice-pull-has-no-preference-between-rebase-and-merge: pull: don't say that merge is "the default strategy"

Merge branch 'ev/pull-already-up-to-date-is-noop'

2021-11-22T05:57:04Z

"git pull" with any strategy when the other side is behind us should succeed as it is a no-op, but doesn't. * ev/pull-already-up-to-date-is-noop: pull: should be noop when already-up-to-date

pull: don't say that merge is "the default strategy"

2021-11-19T17:14:15Z

Git no longer has a default strategy for reconciling divergent branches, because there's no way for Git to know which strategy is appropriate in any particular situation. The initially proposed version in [*], that eventually became 031e2f7a (pull: abort by default when fast-forwarding is not possible, 2021-07-22), dropped this phrase from the message, but it was left in the final version by accident. * https://lore.kernel.org/git/20210627000855.530985-1-alexhenrie24@gmail.com/ Signed-off-by: Alex Henrie Signed-off-by: Junio C Hamano

pull: should be noop when already-up-to-date

2021-11-18T22:38:53Z

The already-up-to-date pull bug was fixed for --ff-only but it did not include the case where --ff or --ff-only are not specified. This updates the --ff-only fix to include the case where --ff or --ff-only are not specified in command line flags or config. Signed-off-by: Erwin Villejo Signed-off-by: Junio C Hamano

Merge branch 'jc/fix-pull-ff-only-when-already-up-to-date'

2021-11-10T23:01:19Z

"git pull --ff-only" and "git pull --rebase --ff-only" should make it a no-op to attempt pulling from a remote that is behind us, but instead the command errored out by saying it was impossible to fast-forward, which may technically be true, but not a useful thing to diagnose as an error. This has been corrected. * jc/fix-pull-ff-only-when-already-up-to-date: pull: --ff-only should make it a noop when already-up-to-date

Merge branch 'ar/fix-git-pull-no-verify'

2021-11-04T19:07:46Z

"git pull --no-verify" did not affect the underlying "git merge". * ar/fix-git-pull-no-verify: pull: honor --no-verify and do not call the commit-msg hook

pull: --ff-only should make it a noop when already-up-to-date

2021-10-29T07:15:39Z

Earlier, we made sure that "git pull --ff-only" (and "git -c pull.ff=only pull") errors out when our current HEAD is not an ancestor of the tip of the history we are merging, but the condition to trigger the error was implemented incorrectly. Imagine you forked from a remote branch, built your history on top of it, and then attempted to pull from them again. If they have not made any update in the meantime, our current HEAD is obviously not their ancestor, and this new error triggers. Without the --ff-only option, we just report that there is no need to pull; we did the same historically with --ff-only, too. Make sure we do not fail with the recently added check to restore the historical behaviour. Reported-by: Kenneth Arnold Helped-by: Jeff King Signed-off-by: Junio C Hamano

pull: honor --no-verify and do not call the commit-msg hook

2021-10-28T16:52:09Z

The option was incorrectly auto-translated to "--no-verify-signatures", which causes the unexpected effect of the hook being called. And an even more unexpected effect of disabling verification of signatures. The manual page describes the option to behave same as the similarly named option of "git merge", which seems to be the original intention of this option in the "pull" command. Signed-off-by: Alexander Riesen Signed-off-by: Junio C Hamano

Merge branch 'js/retire-preserve-merges'

2021-10-18T22:47:56Z

The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch..rebase values t5520: do not use `pull.rebase=preserve`