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

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

2015-06-25T18:02:12Z

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 'pt/pull-log-n' into maint

2015-06-05T19:00:24Z

"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=

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

pull: handle --log=

2015-05-18T18:19:36Z

Since efb779f (merge, pull: add '--(no-)log' command line option, 2008-04-06) git-pull supported the (--no-)log switch and would pass it to git-merge. 96e9420 (merge: Make '--log' an integer option for number of shortlog entries, 2010-09-08) implemented support for the --log= switch, which would explicitly set the number of shortlog entries. However, git-pull does not recognize this option, and will instead pass it to git-fetch, leading to "unknown option" errors. Fix this by matching --log=* in addition to --log and --no-log. Implement a test for this use case. Signed-off-by: Paul Tan Signed-off-by: Junio C Hamano

pull: remove --tags error in no merge candidates case

2015-05-14T16:52:51Z

Since 441ed41 ("git pull --tags": error out with a better message., 2007-12-28), git pull --tags would print a different error message if git-fetch did not return any merge candidates: It doesn't make sense to pull all tags; you probably meant: git fetch --tags This is because at that time, git-fetch --tags would override any configured refspecs, and thus there would be no merge candidates. The error message was thus introduced to prevent confusion. However, since c5a84e9 (fetch --tags: fetch tags *in addition to* other stuff, 2013-10-30), git fetch --tags would fetch tags in addition to any configured refspecs. Hence, if any no merge candidates situation occurs, it is not because --tags was set. As such, this special error message is now irrelevant. To prevent confusion, remove this error message. Signed-off-by: Paul Tan Signed-off-by: Junio C Hamano

merge, pull: stop advising 'commit -a' in case of conflict

2014-08-28T17:29:53Z

'git commit -a' is rarely a good way to mark conflicts as resolved: the user anyway has to go manually through the list of conflicts to do the actual resolution, and it is usually better to use "git add" on each files after doing the resolution. On the other hand, using 'git commit -a' is potentially dangerous, as it makes it very easy to mistakenly commit conflict markers without noticing, and even worse, the user may have started a merge while having local changes that do not overlap with it in the working tree. While we're there, synchronize the 'git pull' and 'git merge' messages: the first was ending with '... and make a commit.', but not the latter. Eventually, git should detect that conflicts have been resolved in the working tree and tailor these messages further. Not only "use git commit -a" could be resurected, but "Fix them up in the work tree" should be dropped when it happens. Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

Sync with maint

2014-06-12T19:22:38Z

* maint: pull: do not abuse 'break' inside a shell 'case'

pull: do not abuse 'break' inside a shell 'case'

2014-06-12T19:15:49Z

It is not C. The code would break under mksh when 'pull.ff' is set: $ git pull /usr/lib/git-core/git-pull[67]: break: can't break Already up-to-date. Signed-off-by: Jacek Konieczny Signed-off-by: Junio C Hamano

git-pull.sh: use the $( ... ) construct for command substitution

2014-04-23T22:17:02Z

The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`$.*$`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto Reviewed-by: Matthieu Moy Signed-off-by: Junio C Hamano