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

Merge branch 'sw/pull-ipv46-passthru' into maint

2017-12-06T17:09:00Z

Contrary to the documentation, "git pull -4/-6 other-args" did not ask the underlying "git fetch" to go over IPv4/IPv6, which has been corrected. * sw/pull-ipv46-passthru: pull: pass -4/-6 option to 'git fetch'

pull: pass -4/-6 option to 'git fetch'

2017-11-21T00:53:48Z

The -4/-6 option should be passed through to 'git fetch' to be consistent with the man page. Signed-off-by: Wei Shuyu Signed-off-by: Junio C Hamano

reduce_heads: fix memory leaks

2017-11-08T02:34:00Z

We currently have seven callers of `reduce_heads(foo)`. Six of them do not use the original list `foo` again, and actually, all six of those end up leaking it. Introduce and use `reduce_heads_replace(&foo)` as a leak-free version of `foo = reduce_heads(foo)` to fix several of these. Fix the remaining leaks using `free_commit_list()`. While we're here, document `reduce_heads()` and mark it as `extern`. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

pull: honor submodule.recurse config option

2017-09-07T00:52:18Z

"git pull" supports a --recurse-submodules option but does not parse the submodule.recurse configuration item to set the default for that option. Meanwhile "git fetch" does support submodule.recurse, producing confusing behavior: when submodule.recurse is enabled, "git pull" recursively fetches submodules but does not update them after fetch. Handle submodule.recurse in "git pull" to fix this. Reported-by: Magnus Homann Signed-off-by: Nicolas Morey-Chaisemartin Signed-off-by: Junio C Hamano

pull: fix cli and config option parsing order

2017-09-07T00:51:29Z

pull parses first the cli options and then the config option. The expected behavior is the other way around, so that config options can not override the cli ones. This patch changes the parsing order so config options are parsed first. Signed-off-by: Nicolas Morey-Chaisemartin Signed-off-by: Junio C Hamano

Merge branch 'ma/parse-maybe-bool'

2017-08-22T17:29:03Z

Code clean-up. * ma/parse-maybe-bool: parse_decoration_style: drop unused argument `var` treewide: deprecate git_config_maybe_bool, use git_parse_maybe_bool config: make git_{config,parse}_maybe_bool equivalent config: introduce git_parse_maybe_bool_text t5334: document that git push --signed=1 does not work Doc/git-{push,send-pack}: correct --sign= to --signed=

treewide: deprecate git_config_maybe_bool, use git_parse_maybe_bool

2017-08-07T20:29:22Z

The only difference between these is that the former takes an argument `name` which it ignores completely. Still, the callers are quite careful to provide reasonable values for it. Once in-flight topics have landed, we should be able to remove git_config_maybe_bool. In the meantime, document it as deprecated in the technical documentation. While at it, document git_parse_maybe_bool. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

Merge branch 'sb/pull-rebase-submodule'

2017-07-13T23:14:54Z

"git pull --rebase --recurse-submodules" learns to rebase the branch in the submodules to an updated base. * sb/pull-rebase-submodule: builtin/fetch cleanup: always set default value for submodule recursing pull: optionally rebase submodules (remote submodule changes only) builtin/fetch: parse recurse-submodules-default at default options parsing builtin/fetch: factor submodule recurse parsing out to submodule config

Merge branch 'bw/config-h'

2017-06-24T21:28:41Z

Fix configuration codepath to pay proper attention to commondir that is used in multi-worktree situation, and isolate config API into its own header file. * bw/config-h: config: don't implicitly use gitdir or commondir config: respect commondir setup: teach discover_git_directory to respect the commondir config: don't include config.h by default config: remove git_config_iter config: create config.h

pull: optionally rebase submodules (remote submodule changes only)

2017-06-23T22:36:53Z

Teach pull to optionally update submodules when '--recurse-submodules' is provided. This will teach pull to run 'submodule update --rebase' when the '--recurse-submodules' and '--rebase' flags are given under specific circumstances. On a rebase workflow: ===================== 1. Both sides change the submodule ------------------------------ Let's assume the following history in a submodule: H---I---J---K---L local branch \ M---N---O---P remote branch and the following in the superproject (recorded submodule in parens): A(H)---B(I)---F(K)---G(L) local branch \ C(N)---D(N)---E(P) remote branch In an ideal world this would rebase the submodule and rewrite the submodule pointers that the superproject points at such that the superproject looks like A(H)---B(I) F(K')---G(L') rebased branch \ / C(N)---D(N)---E(P) remote branch and the submodule as: J---K---L (old dangeling tip) / H---I J'---K'---L' rebased branch \ / M---N---O---P remote branch And if a conflict arises in the submodule the superproject rebase would stop at that commit at which the submodule conflict occurs. Currently a "pull --rebase" in the superproject produces a merge conflict as the submodule pointer changes are conflicting and cannot be resolved. 2. Local submodule changes only ----------------------- Assuming histories as above, except that the remote branch would not contain submodule changes, then a result as A(H)---B(I) F(K)---G(L) rebased branch \ / C(I)---D(I)---E(I) remote branch is desire-able. This is what currently happens in rebase. If the recursive flag is given, the ideal git would produce a superproject as: A(H)---B(I) F(K')---G(L') rebased branch (incl. sub rebase!) \ / C(I)---D(I)---E(I) remote branch and the submodule as: J---K---L (old dangeling tip) / H---I J'---K'---L' locally rebased branch \ / M---N---O---P advanced branch This patch doesn't address this issue, however a test is added that this fails up front. 3. Remote submodule changes only ---------------------- Assuming histories as in (1) except that the local superproject branch would not have touched the submodule the rebase already works out in the superproject with no conflicts: A(H)---B(I) F(P)---G(P) rebased branch (no sub changes) \ / C(N)---D(N)---E(P) remote branch The recurse flag as presented in this patch would additionally update the submodule as: H---I J'---K'---L' rebased branch \ / M---N---O---P remote branch As neither J, K, L nor J', K', L' are referred to from the superproject, no rewriting of the superproject commits is required. Conclusion for 'pull --rebase --recursive' ----------------------------------------- If there are no local superproject changes it is sufficient to call "submodule update --rebase" as this produces the desired results. In case of conflicts, the behavior is the same as in 'submodule update --recursive' which is assumed to be sane. This patch implements (3) only. On a merge workflow: ==================== We'll start off with the same underlying DAG as in (1) in the rebase workflow. So in an ideal world a 'pull --merge --recursive' would produce this: H---I---J---K---L----X \ / M---N---O---P with X as the new merge-commit in the submodule and the superproject as: A(H)---B(I)---F(K)---G(L)---Y(X) \ / C(N)---D(N)---E(P) However modifying the submodules on the fly is not supported in git-merge such that Y(X) is not easy to produce in a single patch. In fact git-merge doesn't know about submodules at all. However when at least one side does not contain commits touching the submodule at all, then we do not need to perform the merge for the submodule but a fast-forward can be done via checking out either L or P in the submodule. This strategy is implemented in 68d03e4a6e (Implement automatic fast-forward merge for submodules, 2010-07-07) already, so to align with the rebase behavior we need to also update the worktree of the submodule. Signed-off-by: Brandon Williams Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano