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

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

doc: typo: s/can not/cannot/ and s/is does/does/

2019-08-05T17:05:24Z

"Can not" suggests one has the option to not do something, whereas "cannot" more strongly suggests something is disallowed or impossible. Noticed "can not", mistakenly used instead of "cannot" in git help glossary, then ran git grep 'can not' and found many other instances. Only files in the Documentation folder were modified. 'Can not' also occurs in some source code comments and some test assertion messages, and there is an error message and translation "can not move directory into itself" which I may fix and submit separately from the documentation change. Also noticed and fixed "is does" in git help fetch, but there are no other occurrences of that typo according to git grep. Signed-off-by: Mark Rushakoff Signed-off-by: Junio C Hamano

docs: say that `--rebase=preserve` is deprecated

2019-05-28T20:22:34Z

As of Git v2.22.0, the `--preserve-merges` backend of `git rebase` will be officially deprecated in favor of the `--rebase-merges` backend. Consequently, `git pull --rebase=preserve` will also be deprected. State this explicitly. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Use proper syntax for replaceables in command docs

2018-05-25T08:16:47Z

The standard for command documentation synopses appears to be: [...] means optional <...> means replaceable [<...>] means both optional and replaceable So fix a number of doc pages that use incorrect variations of the above. Signed-off-by: Robert P. J. Day Signed-off-by: Junio C Hamano

pull: accept --rebase=merges to recreate the branch topology

2018-04-26T03:28:43Z

Similar to the `preserve` mode simply passing the `--preserve-merges` option to the `rebase` command, the `merges` mode simply passes the `--rebase-merges` option. This will allow users to conveniently rebase non-trivial commit topologies when pulling new commits, without flattening them. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano