aboutsummaryrefslogtreecommitdiff
path: root/t/t5521-pull-options.sh
Commit message (Collapse)AuthorAge
* test: test_must_be_empty helperJunio C Hamano2013-06-09
| | | | | | | | | | | | | | | There are quite a lot places where an output file is expected to be empty, and we fail the test when it is not. The output from running the test script with -i -v can be helped if we showed the unexpected contents at that point. We could of course do >expected.empty && test_cmp expected.empty actual but this is commmon enough to be done with a dedicated helper. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: Apply -q and -v options to rebase mode as wellPeter Eisentraut2013-03-16
| | | | | | | | | | | | | git pull passed -q and -v only to git merge, but they can be useful for git rebase as well, so pass them there, too. In particular, using -q shuts up the "Already up-to-date." message. Especially, a new test script runs the same "pull --rebase" twice to make sure both cases are quiet, when it has something to fetch and when it is already up to date. Signed-off-by: Peter Eisentraut <peter@eisentraut.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* fetch --all/--multiple: keep all the fetched branch informationJunio C Hamano2010-02-24
| | | | | | | | | | | | | | | | | | | | | | Since "git fetch" learned "--all" and "--multiple" options, it has become tempting for users to say "git pull --all". Even though it may fetch from remotes that do not need to be fetched from for merging with the current branch, it is handy. "git fetch" however clears the list of fetched branches every time it contacts a different remote. Unless the current branch is configured to merge with a branch from a remote that happens to be the last in the list of remotes that are contacted, "git pull" that fetches from multiple remotes will not be able to find the branch it should be merging with. Make "fetch" clear FETCH_HEAD (unless --append is given) and then append the list of branches fetched to it (even when --append is not given). That way, "pull" will be able to find the data for the branch being merged in FETCH_HEAD no matter where the remote appears in the list of remotes to be contacted by "git fetch". Reported-by: Michael Lukashov Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-fetch --all/--multi: propagate options correctlyJunio C Hamano2010-02-24
| | | | | | | When running a subfetch, the code propagated some options but not others. Propagate --force, --update-head-ok and --keep options as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t5521: fix and modernizeJunio C Hamano2010-02-24
| | | | | | | | | | | | | All of these tests were bogus, as they created new directory and tried to run "git pull" without even running "git init" in there. They were mucking with the repository in $TEST_DIRECTORY. While fixing it, modernize the style not to chdir around outside of subshell. Otherwise a failed test will take us to an unexpected directory and we need to chdir back to the test directory in each test, which is ugly and error prone. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Teach/Fix pull/fetch -q/-v optionsTuncer Ayaz2008-11-14
Implement git-pull --quiet and git-pull --verbose by adding the options to git-pull and fixing verbosity handling in git-fetch. Signed-off-by: Junio C Hamano <gitster@pobox.com>