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

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

2021-11-23T22:48: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: 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`

Merge branch 'js/run-command-close-packs'

2021-09-20T22:20:45Z

The run-command API has been updated so that the callers can easily ask the file descriptors open for packfiles to be closed immediately before spawning commands that may trigger auto-gc. * js/run-command-close-packs: Close object store closer to spawning child processes run_auto_maintenance(): implicitly close the object store run-command: offer to close the object store before running run-command: prettify the `RUN_COMMAND_*` flags pull: release packs before fetching commit-graph: when closing the graph, also release the slab

Close object store closer to spawning child processes

2021-09-09T19:56:11Z

In many cases where we spawned child processes that _may_ trigger a repack, we explicitly closed the object store first (so that the `repack` process can delete the `.pack` files, which would otherwise not be possible on Windows since files cannot be deleted as long as they as still in use). Wherever possible, we now use the new `close_object_store` bit of the `run_command()` API, to delay closing the object store even further. This makes the code easier to maintain because it is now more obvious that we only release those file handles because of those child processes. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

pull: release packs before fetching

2021-09-08T19:17:15Z

On Windows, files cannot be removed nor renamed if there are still handles held by a process. To remedy that, we try to release all open handles to any `.pack` file before e.g. repacking (which would want to remove the original `.pack` file(s) after it is done). Since the `read_cache_unmerged()` and/or the `get_oid()` call in `git pull` can cause `.pack` files to be opened, we need to release the open handles before calling `git fetch`: the latter process might want to spawn an auto-gc, which in turn might want to repack the objects. This commit is similar in spirit to 5bdece0d705 (gc/repack: release packs when needed, 2018-12-15). This fixes https://github.com/git-for-windows/git/issues/3336. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano