git/git-pull.sh, branch v2.5.2

pull: pass upload_pack only when it was given

2015-08-25T23:08:58Z

The upload_pack shell variable is initialized to an empty string, so conditional expansion with ${upload_pack+"$upload_pack"} would not work very well. You need a colon there. Signed-off-by: Junio C Hamano

pull.sh: quote $upload_pack when passing it to git-fetch

2015-07-30T21:14:32Z

The previous code broke for example git pull --upload-pack 'echo --foo' Reported-by: Joey Hess Fix-suggested-by: Junio C Hamano Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

pull: use git-rev-parse --parseopt for option parsing

2015-06-02T20:36:23Z

To enable unambiguous parsing of abbreviated options, bundled short options, separate form options and to provide consistent usage help, use git-rev-parse --parseopt for option parsing. With this, simplify the option parsing code. Signed-off-by: Paul Tan Signed-off-by: Junio C Hamano

pull: handle git-fetch's options as well

2015-06-02T20:36:22Z

While parsing the command-line arguments, git-pull stops parsing at the first unrecognized option, assuming that any subsequent options are for git-fetch, and can thus be kept in the shell's positional parameters list, so that it can be passed to git-fetch via the expansion of "$@". However, certain functions in git-pull assume that the positional parameters do not contain any options: * error_on_no_merge_candidates() uses the number of positional parameters to determine which error message to print out, and will thus print the wrong message if git-fetch's options are passed in as well. * the call to get_remote_merge_branch() assumes that the positional parameters only contains the optional repo and refspecs, and will thus silently fail if git-fetch's options are passed in as well. * --dry-run is a valid git-fetch option, but if provided after any git-fetch options, it is not recognized by git-pull and thus git-pull will continue to run the merge or rebase. Fix these bugs by teaching git-pull to parse git-fetch's options as well. Add tests to prevent regressions. This removes the limitation where git-fetch's options have to come after git-merge's and git-rebase's options on the command line. Update the documentation to reflect this. Signed-off-by: Paul Tan Signed-off-by: Junio C Hamano

Merge branch 'pt/pull-ff-vs-merge-ff'

2015-05-26T20:24:44Z

The pull.ff configuration was supposed to override the merge.ff configuration, but it didn't. * pt/pull-ff-vs-merge-ff: pull: parse pull.ff as a bool or string pull: make pull.ff=true override merge.ff

Merge branch 'pt/pull-log-n'

2015-05-26T20:24:43Z

"git pull --log" and "git pull --no-log" worked as expected, but "git pull --log=20" did not. * pt/pull-log-n: pull: handle --log=

Merge branch 'pt/pull-tags-error-diag'

2015-05-22T19:41:56Z

There was a dead code that used to handle "git pull --tags" and show special-cased error message, which was made irrelevant when the semantics of the option changed back in Git 1.9 days. * pt/pull-tags-error-diag: pull: remove --tags error in no merge candidates case

Merge branch 'jc/merge'

2015-05-19T20:17:57Z

"git merge FETCH_HEAD" learned that the previous "git fetch" could be to create an Octopus merge, i.e. recording multiple branches that are not marked as "not-for-merge"; this allows us to lose an old style invocation "git merge HEAD $commits..." in the implementation of "git pull" script; the old style syntax can now be deprecated. * jc/merge: merge: deprecate 'git merge HEAD ' syntax merge: handle FETCH_HEAD internally merge: decide if we auto-generate the message early in collect_parents() merge: make collect_parents() auto-generate the merge message merge: extract prepare_merge_message() logic out merge: narrow scope of merge_names merge: split reduce_parents() out of collect_parents() merge: clarify collect_parents() logic merge: small leakfix and code simplification merge: do not check argc to determine number of remote heads merge: clarify "pulling into void" special case t5520: test pulling an octopus into an unborn branch t5520: style fixes merge: simplify code flow merge: test the top-level merge driver

pull: parse pull.ff as a bool or string

2015-05-18T18:22:38Z

Since b814da8 (pull: add pull.ff configuration, 2014-01-15) git-pull supported setting --(no-)ff via the pull.ff configuration value. However, as it only matches the string values of "true" and "false", it does not support other boolean aliases such as "on", "off", "1", "0". This is inconsistent with the merge.ff setting, which supports these aliases. Fix this by using the bool_or_string_config function to retrieve the value of pull.ff. Signed-off-by: Paul Tan Reviewed-by: Johannes Schindelin Signed-off-by: Junio C Hamano

pull: make pull.ff=true override merge.ff

2015-05-18T18:22:27Z

Since b814da8 (pull: add pull.ff configuration, 2014-01-15), running git-pull with the configuration pull.ff=false or pull.ff=only is equivalent to passing --no-ff and --ff-only to git-merge. However, if pull.ff=true, no switch is passed to git-merge. This leads to the confusing behavior where pull.ff=false or pull.ff=only is able to override merge.ff, while pull.ff=true is unable to. Fix this by adding the --ff switch if pull.ff=true, and add a test to catch future regressions. Furthermore, clarify in the documentation that pull.ff overrides merge.ff. Signed-off-by: Paul Tan Reviewed-by: Johannes Schindelin Signed-off-by: Junio C Hamano