git/Documentation/git-pull.txt, branch v2.33.6

Merge branch 'en/pull-conflicting-options' into maint

2021-10-12T20:51:36Z

"git pull" had various corner cases that were not well thought out around its --rebase backend, e.g. "git pull --ff-only" did not stop but went ahead and rebased when the history on other side is not a descendant of our history. The series tries to fix them up. * en/pull-conflicting-options: pull: fix handling of multiple heads pull: update docs & code for option compatibility with rebasing pull: abort by default when fast-forwarding is not possible pull: make --rebase and --no-rebase override pull.ff=only pull: since --ff-only overrides, handle it first pull: abort if --ff-only is given and fast-forwarding is impossible t7601: add tests of interactions with multiple merge heads and config t7601: test interaction of merge/rebase/fast-forward flags and options

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

doc: pull: fix rebase=false documentation

2021-07-21T23:34:06Z

"git pull --rebase=false" means we merge their history into ours, but it has been described the other way around. Cc: Stephen Haberman Signed-off-by: Felipe Contreras [jc: updated the log message] Signed-off-by: Junio C Hamano

Merge branch 'dl/merge-autostash'

2020-04-29T23:15:27Z

"git merge" learns the "--autostash" option. * dl/merge-autostash: (22 commits) pull: pass --autostash to merge t5520: make test_pull_autostash() accept expect_parent_num merge: teach --autostash option sequencer: implement apply_autostash_oid() sequencer: implement save_autostash() sequencer: unlink autostash in apply_autostash() sequencer: extract perform_autostash() from rebase rebase: generify create_autostash() rebase: extract create_autostash() reset: extract reset_head() from rebase rebase: generify reset_head() rebase: use apply_autostash() from sequencer.c sequencer: rename stash_sha1 to stash_oid sequencer: make apply_autostash() accept a path rebase: use read_oneliner() sequencer: make read_oneliner() extern sequencer: configurably warn on non-existent files sequencer: make read_oneliner() accept flags sequencer: make file exists check more efficient sequencer: stop leaking buf ...

Merge branch 'dr/doc-recurse-submodules'

2020-04-28T22:50:01Z

Documentation updates around the "--recurse-submodules" option. * dr/doc-recurse-submodules: doc: --recurse-submodules mostly applies to active submodules doc: be more precise on (fetch|push).recurseSubmodules doc: explain how to deactivate submodule.recurse completely doc: document --recurse-submodules for reset and restore doc: list all commands affected by submodule.recurse

pull: pass --autostash to merge

2020-04-10T16:28:02Z

Before, `--autostash` only worked with `git pull --rebase`. However, in the last patch, merge learned `--autostash` as well so there's no reason why we should have this restriction anymore. Teach pull to pass `--autostash` to merge, just like it did for rebase. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

doc: --recurse-submodules mostly applies to active submodules

2020-04-06T20:42:43Z

The documentation refers to "initialized" or "populated" submodules, to explain which submodules are affected by '--recurse-submodules', but the real terminology here is 'active' submodules. Update the documentation accordingly. Some terminology: - Active is defined in gitsubmodules(7), it only involves the configuration variables 'submodule.active', 'submodule..active' and 'submodule..url'. The function submodule.c::is_submodule_active checks that a submodule is active. - Populated means that the submodule's working tree is present (and the gitfile correctly points to the submodule repository), i.e. either the superproject was cloned with ` --recurse-submodules`, or the user ran `git submodule update --init`, or `git submodule init []` and `git submodule update []` separately which populated the submodule working tree. This does not involve the 3 configuration variables above. - Initialized (at least in the context of the man pages involved in this patch) means both "populated" and "active" as defined above, i.e. what `git submodule update --init` does. The --recurse-submodules option mostly affects active submodules. An exception is `git fetch` where the option affects populated submodules. As a consequence, in `git pull --recurse-submodules` the fetch affects populated submodules, but the resulting working tree update only affects active submodules. In the documentation of `git-pull`, let's distinguish between the fetching part which affects populated submodules, and the updating of worktrees, which only affects active submodules. Signed-off-by: Damien Robert Helped-by: Philippe Blain Signed-off-by: Junio C Hamano

doc: be more precise on (fetch|push).recurseSubmodules

2020-04-06T20:42:43Z

The default value also depends on the value of submodule.recurse. Use this opportunity to correct some grammar mistakes in Documentation/config/fetch.txt signaled by Robert P. J. Day. Also mention `fetch.recurseSubmodules` in fetch-options.txt. In git-push.txt, `push.recurseSubmodules` is implicitly mentioned (by explaining how to disable it), so no need to add it there. Lastly add a link to `git-fetch` in `git-pull.txt` to explain the meaning of `--recurse-submodules` there. Signed-off-by: Damien Robert Signed-off-by: Junio C Hamano

pull doc: correct outdated description of an example

2020-04-05T22:00:04Z

Since f269048754 (fetch: opportunistically update tracking refs, 2013-05-11), the underlying `git fetch` in `git pull ` updates the configured remote-tracking branch for . However, an example in the 'Examples' section of the `git pull` documentation still states that this is not the case. Correct the description of this example. Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano